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