Hibernate Mapping Question

I have a table called employee_table. Currently, the Identifier for this table is empid which is something my company issues and I import into my table. So I don't have any kind of autoincremented id or anything like that.

What I am wondering is

Is the ID attribute of an hbm file required

If it is, how do I specify the generator for an ID that is not really generated

Thanks.

ID is a required child node of the class element. The Hibernate docs are very insistant about proper relational identity, so it's pretty ridgidly enforced in their design. I'm not sure I understand exactly what you are trying to do though - does your application add the (not guarenteed to be unique) fields to the table, then later on you assign a PK using some other process? If I'm there or thereabouts then you can map only the fields you are going to update as one big composite key. I've used this approach to get round a legacy DB where some fool had modelled a table without a PK (which of course means the table is by defintion not a relation).

If instead you import a new PK, then add the other data - i.e. INSERT with just the PK, then UPDATE - you can get away with just using an "assigned" identifier strategy.

Your other alternative is to implement the IdentifierGenerator yourself to supply the PK from whatever source you have.
[ August 06, 2004: Message edited by: Paul Sturrock ]

The docs have more information about the assigned identity.

- Peter

Well, I have a table:

employee_table
empid
firstname
lastname
department
phone
mailstop
email
------------------------

empid is guarnteed to be unique becaue this is an ID that each employee gets when they are hired. There is no chance of any duplicates. So I thought this would be a good PK for my table. Of course, this was before I was trying to add Hibernate to my app.

My app has a function where I get a list of employees, I check for changes and then I add new employees into the table. So my app handles the PK generation. Now, the Asigned Identifiers looks like what I would want to use in this situation. However, I would like to ask if anyone sees anything wrong with doing it this way. What advantage would I gain by adding an "identity" identifier that is created by MySQL?

Ok, here is what I have done. I decided to just add an identity column to my table and I changed the way I was filling my object using Hibernate. Things I think are simpler now and of course, I conformed to the standard.

Originally posted by Gregg Bolinger:
What advantage would I gain by adding an "identity" identifier that is created by MySQL?

None. From the sound of it you need to generate your own unique empids anyway, so why not use it as the primary key? It will make mapping relationships a little bit easier as well.

- Peter

Originally posted by Peter den Haan:
None. From the sound of it you need to generate your own unique empids anyway, so why not use it as the primary key? It will make mapping relationships a little bit easier as well.

- Peter

I don't generate them. And employee is hired. They are given an Employee ID number. I get the list of Employees. It's already there for me.

So my app handles the PK generation

In which case you use the "assigned" strategy, which is specifically there for objects with natural PKs.

I feel this will be a more elegant way of application assigning identifiers (as opposed to having Hibernate generate them).

You may use the assigned generator. This special generator will use the identifier value already assigned to the object's iden-tifier property.

<id name="id" type="long" column="uid" unsaved-value="0">
<generator class="assigned"/>
</id>

Cheers
Ankur

Originally posted by Ankur Srivastava:
I feel this will be a more elegant way of application assigning identifiers...

Elegance is subjective

IMO this is less elegant than transparently generated IDs because it requires considerable analysis to use natural keys. It is a battle trying to maintain unique keys efficiently without them. You necessarily start having to create composite primary keys to achieve what you hope is a unique set.

There are several excellent counter-arguments that suggest using natural keys but on balance the generated keys are of far more practical value.