Optional auto-generation

[dkrizic]

Hi!

When I have an entity bean and I define

@Id

then, I must provide the primary key value. By using

@Id(generator=GeneratorType.AUTO)

then the ID is generated automatically. But when I now define a primary key value on my own, this value will be ignored:

User u = new User();
u.setId( 1000 );
u = em.persist( u );
System.out.println( u.getId() );

prints 1, not 1000

How can I have an optional auto generation.

[epbernard]

Besides it is a really bad design, you can't do that because when your sequence or you identity will encoun ter a value you've et, you'll be in deep trouble.
You really really should not try to do so.

[dkrizic]

But the Real World[tm] requires something like this. Batch jobs usually insert values that have predefined primary keys and other applications get a generated key where the sequence works in another number range.

Besides of this: Is there a technical solution for this?

[kkoster]

Yes, the Real World[tm] does require something like this. But it is normally outside the scope of normal business logic. (e.g. fixing up data, conversions, etc.) In these cases you probably should work outside the normal business logic infrastructure. You may want to do this entirely outside of the J2EE environment. Or, if it is a regular occurance and you want to keep it in the EJB container, construct special instances of the particular entities involved that deal with these special conditions leave the generation annotation off. (it defaults to NONE) You may, of course, have to fix up any data that is used by the Id generator for the normal business logic after you are finished.

[dkrizic]

But if I turn off the generator - where do I get the primary keys from when I need them?

[kkoster]

Let me clarify, when I said "construct special instances of the particular entities" that would mean a seperate implementation of these entities for the particular needs of the batch, non-normal process.

For instance, you have an entity Widget described for you normal business processes. You would create a seperate implementation of the entity WidgetSpecial that would simple have a different @Id annotation. In fact you could probably construct a base class WidgetBase that contains all necessary business logic and is annotation free and have Widget and WidgetSpecial derive from it with the appropriate annotations.

This actually begs some interesting questions. Are entity annotations "final"? If I derive an some entity from an annotated entity 1) does it inherit all of the annotations? 2) does the container recognize these annotations and allow the entity to participate in the persistence framework? 3) can I override annotations on the derived class and change its persistence behaviour?

I eagerly await the reply of the experts.

[epbernard]

The technical solution would be a user defined id generator, this is not possible right now, but this is not an enormous amount of work.

This actually begs some interesting questions. Are entity annotations "final"? If I derive an some entity from an annotated entity 1) does it inherit all of the annotations? 2) does the container recognize these annotations and allow the entity to participate in the persistence framework? 3) can I override annotations on the derived class and change its persistence behaviour?

Well this is a dangerous area :-)
1) If the sub entity has @Entity, it will be part of the entity hierarchy and thus e persisted as a subclass (see @Inheritance for more details)
2) thus yes.
3) Basically no. Overriding is allowed through XML, but altering a sub entity behavior for the same Entity manager configuration could have lots of side effects.

[dkrizic]

I did not look into the code of the current "AUTO"-Implementation but I think the only needed change is

Long primaryKey;
if( objectToBePersisted.getPrimaryKey() != null ) {
primaryKey = objectToBePersisted.getPrimaryKey();
} else {
primaryKey = generatePrimaryKey();
}

Or do I see this *too* simple?

...darko

[epbernard]

"dkrizic" wrote:
Or do I see this *too* simple?

It does not work when cascading the persist and merge operations is performed