This statement isn't totally accurate, though is likely a correct observation for the database you are using.<br><br>The AUTO strategy tells the persistence provider to select the default strategy for the database being used, as stated in the JavaDoc:<br>
<br>"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."<br>
<br>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.<br><br>The best solution here is to allow the forge user to customize what value goes into the @GenerationStrategy value.<br>
<br>Keep in mind even that value can be overridden using an orm.xml descriptor. See <a href="http://java.sun.com/xml/ns/persistence/orm_2_0.xsd">http://java.sun.com/xml/ns/persistence/orm_2_0.xsd</a> for the schema and examples.<br>
<br>-Dan<br><br><div class="gmail_quote">On Fri, May 4, 2012 at 10:31 AM, Ryan Bradley <span dir="ltr"><<a href="mailto:rbradley@redhat.com" target="_blank">rbradley@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Okay, so say we have two different entities in our scaffolded webapp,<br>
Customer and Account. Under the current GenerationStrategy:<br>
<br>
I create a Customer object, and that will have an ID of 1.<br>
<br>
I create an Account object, and that will have an ID of 2, even though<br>
it is the first (and only) Account in the database.<br>
<br>
Using GenerationStrategy.IDENTITY, both objects will have identities of<br>
1, i.e. there are separate sets of IDs kept for each table in the<br>
database. One useful case that I can think of is that, in the Spring<br>
scaffold implementation, individual objects can be navigated to in the<br>
URL using their ID (e.g. /customers/1 would go to the Customer object in<br>
the database with an ID of 1). Therefore, it might cause confusion if a<br>
user was trying to navigate using the URL but not necessarily knowing<br>
the ID of the object they are looking for (even if they know its ID<br>
relative to other objects of the same type).<br>
<br>
Does that clarify things?<br>
<br>
Cheers,<br>
Ryan<br>
<div class="HOEnZb"><div class="h5"><br>
On 05/04/2012 10:19 AM, George Gastaldi wrote:<br>
>> Thinking of scaffold implementations, it might be best if a separate set<br>
>> of IDs was generated for each separate entity.<br>
> I don´t think I get it. Can you give a practical example ?<br>
><br>
> Regards,<br>
><br>
> George Gastaldi<br>
><br>
> 2012/5/4 Ryan Bradley<<a href="mailto:rbradley@redhat.com">rbradley@redhat.com</a>>:<br>
>> Greetings all,<br>
>><br>
>> Currently, the entity plugin annotates the ID primary key with<br>
>> @GeneratedValue. This annotation uses the default generation strategy,<br>
>> GenerationType.AUTO, to generate the values for this key. Using this<br>
>> strategy, the same set of values is used for all entity tables. In<br>
>> other words, you cannot have two entities with the same value for ID, as<br>
>> it is incremented with each entity creation rather than with each<br>
>> creation of an entity of a specific type.<br>
>><br>
>> Thinking of scaffold implementations, it might be best if a separate set<br>
>> of IDs was generated for each separate entity. I believe that this can<br>
>> be accomplished by annotating the field with<br>
>> @GeneratedValue(strategy=GenerationType.IDENTITY). I was thinking of<br>
>> modifying the ScaffoldPlugin to change the GenerationType on this<br>
>> annotation in the generateFromEntity method (from-entity command).<br>
>><br>
>> Any objections to this change?<br>
>><br>
>> Cheers,<br>
>> Ryan<br>
>> _______________________________________________<br>
>> forge-dev mailing list<br>
>> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
> _______________________________________________<br>
> forge-dev mailing list<br>
> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div>Dan Allen</div>Principal Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><div><a href="http://google.com/profiles/dan.j.allen" target="_blank">http://google.com/profiles/dan.j.allen</a><br>
<a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br></div><br>