[forge-dev] @GeneratedValue Strategy

[Max Rydahl Andersen]

just to be specific its first affected by the JPA provider (hibernate, eclipse link etc. can be different) and then the database.

The problem you are talking about here is the reason why .AUTO was defined in the JPA spec - to allow you in source to have something that 
should work across all providers - of course if you switch providers midstream strange things could happen.

But in short it means that .AUTO is the only sensible default anything that autogenerates code can use and if .AUTO did not exist you couldn't do anything sensible since it would all depend on the database and your model.

But yes, for those wanting to tweak and have their generation optimized for their database specific usecases some customization of the generation would be good.

/max

On May 20, 2012, at 22:22 , Dan Allen wrote:

> This statement isn't totally accurate, though is likely a correct observation for the database you are using.
> 
> The AUTO strategy tells the persistence provider to select the default strategy for the database being used, as stated in the JavaDoc:
> 
> "Indicates that the persistence provider should pick an appropriate strategy for the particular database. The AUTO generation strategy may expect a database resource to exist, or it may attempt to create one. A vendor may provide documentation on how to create such resources in the event that it does not support schema generation or cannot create the schema resource at runtime."
> 
> So this could mean it's a global identifier (as in your case), it could be a table (auto-increment) identifier or it could be any other option. It's totally up in the air.
> 
> The best solution here is to allow the forge user to customize what value goes into the @GenerationStrategy value.
> 
> Keep in mind even that value can be overridden using an orm.xml descriptor. See http://java.sun.com/xml/ns/persistence/orm_2_0.xsd for the schema and examples.
> 
> -Dan
> 
> On Fri, May 4, 2012 at 10:31 AM, Ryan Bradley <rbradley at redhat.com> wrote:
> Okay, so say we have two different entities in our scaffolded webapp,
> Customer and Account.  Under the current GenerationStrategy:
> 
> I create a Customer object, and that will have an ID of 1.
> 
> I create an Account object, and that will have an ID of 2, even though
> it is the first (and only) Account in the database.
> 
> Using GenerationStrategy.IDENTITY, both objects will have identities of
> 1, i.e. there are separate sets of IDs kept for each table in the
> database.  One useful case that I can think of is that, in the Spring
> scaffold implementation, individual objects can be navigated to in the
> URL using their ID (e.g. /customers/1 would go to the Customer object in
> the database with an ID of 1).  Therefore, it might cause confusion if a
> user was trying to navigate using the URL but not necessarily knowing
> the ID of the object they are looking for (even if they know its ID
> relative to other objects of the same type).
> 
> Does that clarify things?
> 
> Cheers,
> Ryan
> 
> On 05/04/2012 10:19 AM, George Gastaldi wrote:
> >> Thinking of scaffold implementations, it might be best if a separate set
> >> of IDs was generated for each separate entity.
> > I don´t think I get it. Can you give a practical example ?
> >
> > Regards,
> >
> > George Gastaldi
> >
> > 2012/5/4 Ryan Bradley<rbradley at redhat.com>:
> >> Greetings all,
> >>
> >> Currently, the entity plugin annotates the ID primary key with
> >> @GeneratedValue.  This annotation uses the default generation strategy,
> >> GenerationType.AUTO, to generate the values for this key.  Using this
> >> strategy, the same set of values is used for all entity tables.  In
> >> other words, you cannot have two entities with the same value for ID, as
> >> it is incremented with each entity creation rather than with each
> >> creation of an entity of a specific type.
> >>
> >> Thinking of scaffold implementations, it might be best if a separate set
> >> of IDs was generated for each separate entity.  I believe that this can
> >> be accomplished by annotating the field with
> >> @GeneratedValue(strategy=GenerationType.IDENTITY).  I was thinking of
> >> modifying the ScaffoldPlugin to change the GenerationType on this
> >> annotation in the generateFromEntity method (from-entity command).
> >>
> >> Any objections to this change?
> >>
> >> Cheers,
> >> Ryan
> >> _______________________________________________
> >> forge-dev mailing list
> >> forge-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
> 
> 
> 
> -- 
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
> 
> http://google.com/profiles/dan.j.allen
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> 
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev