Yeah, I think this is a really good idea to support, but like Rafael said, not all databases support this. So the new option you added for this is a good solution I think!<br><br>~Lincoln<br><br><div class="gmail_quote">On Fri, May 4, 2012 at 7:48 AM, George Gastaldi <span dir="ltr"><<a href="mailto:gegastaldi@gmail.com" target="_blank">gegastaldi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Now I get it. :)<br>
<br>
I always believed that this behavior is related to the supported<br>
features on the database you use.<br>
<br>
For example, if you use an Oracle DB, you can have a sequence for each<br>
table, but that might mean having to place a @SequenceGenerator on<br>
each entity.<br>
<br>
It would be nice to have this feature when creating the JPA entity.<br>
You may want to provide another option in method<br>
org.jboss.forge.spec.javaee.jpa.EntityPlugin.newEntity(String, String)<br>
<br>
Hope that helps,<br>
<div class="HOEnZb"><div class="h5"><br>
George Gastaldi<br>
<br>
2012/5/4 Ryan Bradley <<a href="mailto:rbradley@redhat.com">rbradley@redhat.com</a>>:<br>
> 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>
><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>
<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>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>"Simpler is better."<br>