[forge-dev] @GeneratedValue Strategy

[Dan Allen]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20120520/6a005d50/attachment.html