5:22 a.m.
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(a)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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)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