You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Luther Baker <lu...@gmail.com> on 2009/02/10 02:35:52 UTC
Hibernate ID
This is a little offtopic - so I apologize in advance but I'm building
Tapestry applications and have a Hibernate question that I'd like to pose
here.
Is there preferred type for simple Hibernate IDs?
Simply stated, I'm asking about the two orthogonal choices: (native vs
object, range or size)
Is an int preferred to an Integer? Is there a compelling argument for either
native or Object?
Is an Integer preferred to a Long (if the extra range of the the Long is
unecessary)? For instance, using hsqldb - would a Long possibly require TWO
columns and an Integer only one?
If anyone has time to chime in briefly, I'm just asking for the most
generally used/accepted practices.
-Luther
Re: Hibernate ID
Posted by Luther Baker <lu...@gmail.com>.
Thank you Thiago.
-Luther
On Mon, Feb 9, 2009 at 8:53 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Em Mon, 09 Feb 2009 22:35:52 -0300, Luther Baker <lu...@gmail.com>
> escreveu:
>
> This is a little offtopic - so I apologize in advance but I'm building
>> Tapestry applications and have a Hibernate question that I'd like to pose
>> here.
>> Is there preferred type for simple Hibernate IDs?
>>
>
> I always use an artificial (i.e. a column that is used only as id, not
> being used to store real data) integer column generated by the DBMS as a
> table primary key. I always use Integer, unless I expect the number of rows
> to be huge. In that cases, I use Long.
>
> By the way, *never* use compound primary keys or any natural id column.
> That's my advice. It's simple, it's fast, it prevents some very bad problems
> when you need to change the database structure.
>
> Simply stated, I'm asking about the two orthogonal choices: (native vs
>> object, range or size)
>> Is an int preferred to an Integer? Is there a compelling argument for
>> either native or Object?
>>
>
> I guess that you mean "primite" when you mean "native".
> Native types in Java can't have null values, so, for primary key
> properties, a Integer is a much better fit than an int.
>
> Is an Integer preferred to a Long (if the extra range of the the Long is
>> unecessary)?
>>
>
> Yes.
>
> For instance, using hsqldb - would a Long possibly require TWO columns and
>> an Integer only one?
>>
>
> No. A Long would require a 64 bits column type in the DBMS.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Hibernate ID
Posted by Ulrich Stärk <ul...@spielviel.de>.
I see.
Thanks for explaining. Never thought about this as a potential problem.
Uli
Geoff Callender schrieb:
> Yep, the database will never see a null value, but a new entity needs
> null id to differentiate it from an entity with 0 id. If you tell
> Hibernate to auto-gen the id with HSQLDB then the first row will have 0 id.
>
> Geoff
>
> On 10/02/2009, at 8:33 PM, Ville Virtanen wrote:
>
>>
>> Sometimes if you want to assign the id an not let the DB do it for you
>> it is
>> good to be able to have null values. Also checkin whether the object is
>> already saved can be achieved by just checking id != null.
>>
>> Primitive int defaults to zero without initialization?
>>
>> - Ville
>>
>>
>> Ulrich Stärk wrote:
>>>
>>> Thiago H. de Paula Figueiredo schrieb:
>>>> Em Mon, 09 Feb 2009 22:35:52 -0300, Luther Baker
>>>> <lu...@gmail.com>
>>>> escreveu:
>>>>
>>>>> Simply stated, I'm asking about the two orthogonal choices: (native vs
>>>>> object, range or size)
>>>>> Is an int preferred to an Integer? Is there a compelling argument for
>>>>> either native or Object?
>>>>
>>>> I guess that you mean "primite" when you mean "native".
>>>> Native types in Java can't have null values, so, for primary key
>>>> properties, a Integer is a much better fit than an int.
>>>
>>> Why is that? I couldn't imagine a case where you want your primary key
>>> value to be NULL (apart from the fact that I don't know any DBMS that
>>> allows that).
>>>
>>> Uli
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Hibernate-ID-tp21926024p21930330.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate ID
Posted by Geoff Callender <ge...@gmail.com>.
Yep, the database will never see a null value, but a new entity needs
null id to differentiate it from an entity with 0 id. If you tell
Hibernate to auto-gen the id with HSQLDB then the first row will have
0 id.
Geoff
On 10/02/2009, at 8:33 PM, Ville Virtanen wrote:
>
> Sometimes if you want to assign the id an not let the DB do it for
> you it is
> good to be able to have null values. Also checkin whether the object
> is
> already saved can be achieved by just checking id != null.
>
> Primitive int defaults to zero without initialization?
>
> - Ville
>
>
> Ulrich Stärk wrote:
>>
>> Thiago H. de Paula Figueiredo schrieb:
>>> Em Mon, 09 Feb 2009 22:35:52 -0300, Luther Baker <lutherbaker@gmail.com
>>> >
>>> escreveu:
>>>
>>>> Simply stated, I'm asking about the two orthogonal choices:
>>>> (native vs
>>>> object, range or size)
>>>> Is an int preferred to an Integer? Is there a compelling argument
>>>> for
>>>> either native or Object?
>>>
>>> I guess that you mean "primite" when you mean "native".
>>> Native types in Java can't have null values, so, for primary key
>>> properties, a Integer is a much better fit than an int.
>>
>> Why is that? I couldn't imagine a case where you want your primary
>> key
>> value to be NULL (apart from the fact that I don't know any DBMS that
>> allows that).
>>
>> Uli
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Hibernate-ID-tp21926024p21930330.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate ID
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, Feb 10, 2009 at 7:33 AM, Ville Virtanen
<vi...@cerion.fi> wrote:
> Sometimes if you want to assign the id an not let the DB do it for you it is
> good to be able to have null values. Also checkin whether the object is
> already saved can be achieved by just checking id != null.
Perfect explanation. Checking id != null is exactly what Hibernate
does when it wants to know if a given object exists in the database or
not.
> Primitive int defaults to zero without initialization?
Any Java primitive integer type defaults to zero without initialization.
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate ID
Posted by Ville Virtanen <vi...@cerion.fi>.
Sometimes if you want to assign the id an not let the DB do it for you it is
good to be able to have null values. Also checkin whether the object is
already saved can be achieved by just checking id != null.
Primitive int defaults to zero without initialization?
- Ville
Ulrich Stärk wrote:
>
> Thiago H. de Paula Figueiredo schrieb:
>> Em Mon, 09 Feb 2009 22:35:52 -0300, Luther Baker <lu...@gmail.com>
>> escreveu:
>>
>>> Simply stated, I'm asking about the two orthogonal choices: (native vs
>>> object, range or size)
>>> Is an int preferred to an Integer? Is there a compelling argument for
>>> either native or Object?
>>
>> I guess that you mean "primite" when you mean "native".
>> Native types in Java can't have null values, so, for primary key
>> properties, a Integer is a much better fit than an int.
>
> Why is that? I couldn't imagine a case where you want your primary key
> value to be NULL (apart from the fact that I don't know any DBMS that
> allows that).
>
> Uli
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Hibernate-ID-tp21926024p21930330.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate ID
Posted by "Filip S. Adamsen" <fs...@fsadev.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
There's actually no way - at least according to the documentation, my
own experience, and Google - to specify an unsaved-value using just
annotations. You'd have to use a mapping file for this. But apart from
that, Jonathan is spot on. :)
/Filip
On 2009-02-10 12:16, Jonathan O'Connor wrote:
> Uli,
> Using Object for key fields is a standard micro pattern in JPA and
> Hibernate. Of course, the DB does not want to save null as a key field
> value, but the most people get the entity manager to auto-generate keys
> for their objects.
>
> By leaving the key as null, the entity manager knows that it needs to
> persist the object, generating a key for it. This is a handy pattern,
> when you want to create a parent object with several children, and then
> persist the whole object tree in one call (otherwise, you would have to
> persist the tree, one object at a time, from the bottom up - Yikes!).
> JPA/Hibernate can only do this if it knows what a null key value is, and
> in Java that is of course, null. I think (from memory) you can define a
> specific value as a null, so you could use an int or a long as a key
> field type, and then specify, for example, -999, as the null value.
> Then, you have to set the key field to -999 somewhere, and this is all
> too much work for most people, therefore, they use Object key field values!
>
> Ciao,
> Jonathan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEcBAEBAgAGBQJJkd4/AAoJEEfiH7PpjaMnoDwH/1SdtbIjF0uqxbqe8GJONrty
cYM5Y9Nyh7KTVrNCHaFd0me6TgTYUpjvZnwzIufIZmIA/pp05PcmhpoN2DLXbT/o
6Ixx+yFDQdO0RX2D7fUEk+Gtpl55pvZ63UMWNPbGZcqU1FOLaie6s1Qm9p0NYCmN
BcrXRtKDfkaJUN/ayKflukK3UAtkdpW25R183JsEOzncBkBB3XynTYQk0oWXcTEF
kmVz8+Ki9y+ZBPPDp/M+P+IkTK+DNw979uAUiaxHtPb0eueew9D365ewUpstKuxt
95K28mlpkKxwbQYXUHAC5buNJzMdro4bspGZ+UPwbUAg3vJ1WagLKuJYhCEytv8=
=jyxQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate ID
Posted by Jonathan O'Connor <ni...@eircom.net>.
Uli,
Using Object for key fields is a standard micro pattern in JPA and
Hibernate. Of course, the DB does not want to save null as a key field
value, but the most people get the entity manager to auto-generate keys
for their objects.
By leaving the key as null, the entity manager knows that it needs to
persist the object, generating a key for it. This is a handy pattern,
when you want to create a parent object with several children, and then
persist the whole object tree in one call (otherwise, you would have to
persist the tree, one object at a time, from the bottom up - Yikes!).
JPA/Hibernate can only do this if it knows what a null key value is, and
in Java that is of course, null. I think (from memory) you can define a
specific value as a null, so you could use an int or a long as a key
field type, and then specify, for example, -999, as the null value.
Then, you have to set the key field to -999 somewhere, and this is all
too much work for most people, therefore, they use Object key field values!
Ciao,
Jonathan
On 10/02/2009 08:08, Ulrich Stärk wrote:
> Thiago H. de Paula Figueiredo schrieb:
>> Em Mon, 09 Feb 2009 22:35:52 -0300, Luther Baker
>> <lu...@gmail.com> escreveu:
>>
>>> Simply stated, I'm asking about the two orthogonal choices: (native vs
>>> object, range or size)
>>> Is an int preferred to an Integer? Is there a compelling argument
>>> for either native or Object?
>>
>> I guess that you mean "primite" when you mean "native".
>> Native types in Java can't have null values, so, for primary key
>> properties, a Integer is a much better fit than an int.
>
> Why is that? I couldn't imagine a case where you want your primary key
> value to be NULL (apart from the fact that I don't know any DBMS that
> allows that).
>
> Uli
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate ID
Posted by Ulrich Stärk <ul...@spielviel.de>.
Thiago H. de Paula Figueiredo schrieb:
> Em Mon, 09 Feb 2009 22:35:52 -0300, Luther Baker <lu...@gmail.com>
> escreveu:
>
>> Simply stated, I'm asking about the two orthogonal choices: (native vs
>> object, range or size)
>> Is an int preferred to an Integer? Is there a compelling argument for
>> either native or Object?
>
> I guess that you mean "primite" when you mean "native".
> Native types in Java can't have null values, so, for primary key
> properties, a Integer is a much better fit than an int.
Why is that? I couldn't imagine a case where you want your primary key
value to be NULL (apart from the fact that I don't know any DBMS that
allows that).
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate ID
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 09 Feb 2009 22:35:52 -0300, Luther Baker <lu...@gmail.com>
escreveu:
> This is a little offtopic - so I apologize in advance but I'm building
> Tapestry applications and have a Hibernate question that I'd like to pose
> here.
> Is there preferred type for simple Hibernate IDs?
I always use an artificial (i.e. a column that is used only as id, not
being used to store real data) integer column generated by the DBMS as a
table primary key. I always use Integer, unless I expect the number of
rows to be huge. In that cases, I use Long.
By the way, *never* use compound primary keys or any natural id column.
That's my advice. It's simple, it's fast, it prevents some very bad
problems when you need to change the database structure.
> Simply stated, I'm asking about the two orthogonal choices: (native vs
> object, range or size)
> Is an int preferred to an Integer? Is there a compelling argument for
> either native or Object?
I guess that you mean "primite" when you mean "native".
Native types in Java can't have null values, so, for primary key
properties, a Integer is a much better fit than an int.
> Is an Integer preferred to a Long (if the extra range of the the Long is
> unecessary)?
Yes.
> For instance, using hsqldb - would a Long possibly require TWO columns
> and an Integer only one?
No. A Long would require a 64 bits column type in the DBMS.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org