9:15 a.m.
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
9:19 a.m.
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
9:31 a.m.
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
9:42 a.m.
I think IDENTITY strategy is not supported by all databases..
2012/5/4 Ryan Bradley <rbradley(a)redhat.com>
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
--
<http://www.advancedit.com.br/>Att,
Rafael M. Pestano
Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
Graduando em Ciência da Computação UFRGS
http://code.google.com/p/jsf-conventions-framework/
http://rpestano.wordpress.com/
@realpestano
9:48 a.m.
Now I get it. :)
I always believed that this behavior is related to the supported
features on the database you use.
For example, if you use an Oracle DB, you can have a sequence for each
table, but that might mean having to place a @SequenceGenerator on
each entity.
It would be nice to have this feature when creating the JPA entity.
You may want to provide another option in method
org.jboss.forge.spec.javaee.jpa.EntityPlugin.newEntity(String, String)
Hope that helps,
George Gastaldi
2012/5/4 Ryan Bradley <rbradley(a)redhat.com>:
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
11:26 a.m.
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!
~Lincoln
On Fri, May 4, 2012 at 7:48 AM, George Gastaldi <gegastaldi(a)gmail.com>wrote:
Now I get it. :)
I always believed that this behavior is related to the supported
features on the database you use.
For example, if you use an Oracle DB, you can have a sequence for each
table, but that might mean having to place a @SequenceGenerator on
each entity.
It would be nice to have this feature when creating the JPA entity.
You may want to provide another option in method
org.jboss.forge.spec.javaee.jpa.EntityPlugin.newEntity(String, String)
Hope that helps,
George Gastaldi
2012/5/4 Ryan Bradley <rbradley(a)redhat.com>:
> 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
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
5:15 a.m.
Just for the records, TWIMC :-)
I really was surprised to find this behavior of hibernate generating a
"hibernate_sequence" on MySQL, where the autoincrement is IMHO the most
simple and elegant way to create/use a technical primary key - which is
in the end the reason for the initially desribed behavior of the
incrementing id from Ryan.
(Similar to the discussion on "Serializeable not getting a default
serialVersionUID" the question is: should a tool like Forge provide a
functional core to build on or should it "evangelize" a certain -
debatable - implementation practice.)
In this case the reason for the discussed behavior is the new
AnnotationMapping introduced in Hibernate.
See: 5.1.2.2. Identifier generator in
http://docs.jboss.org/hibernate/orm/3.6/reference/en-US/html/mapping.html
private static String generatorType(GenerationType generatorEnum,
Mappings mappings) {
boolean useNewGeneratorMappings =
mappings.useNewGeneratorMappings();
switch ( generatorEnum ) {
case IDENTITY:
return "identity";
case AUTO:
return useNewGeneratorMappings
?
org.hibernate.id.enhanced.SequenceStyleGenerator.class.getName()
: "native";
The old mapping "native" would have been the mapping causing the use of
"auto_increment", if available.
So there would be two possibilities to react to the issue per default:
- place a property in persistence.xml:
<property name="hibernate.id.new_generator_mappings"
value="false"/>
- set GenerationType.IDENTITY per default
thus excluding technically Databases not supporting autoincrement
Unfortunately both are not really attractive :-/
Thomas
3:22 p.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
4:58 a.m.
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
4372
days inactive
4389
days old
8 comments
7 participants
participants (7)
-
Dan Allen -
George Gastaldi -
Lincoln Baxter, III -
Max Rydahl Andersen -
Rafael Pestano -
Ryan Bradley -
Thomas Frühbeck