You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by Thomas Fischer <tf...@apache.org> on 2006/12/02 13:18:53 UTC
Re: Primitives or not
On Fri, 1 Dec 2006, Thomas Vandahl wrote:
> Greg Monroe wrote:
>> On the record side of things, I can't see that it's
>> a big problem to keep supporting the primitive XML
>> option. Let the application designer decided whether
>> to use primitive or objects via this. It's only a
>> VERY small set of template code that's required to
>> create primitive getter/setters. Everything internally
>> can be object or not.
>
> I don't think so. As Torque works now, you can define a column to be a
> primitive (int) and Nullable at the same time. In Torque you have no way
> to decide whether this column is null or 0 (which is what Torque sets).
> Objects can really be null and so you can distinguish between the two
> cases. So this is the much cleaner approach.
>
> The other way round, you won't be able to store null in such a table,
> simply because the primitive value cannot be null.
>
There is a similar problem for primary keys. E.g. if a promitive integer
is used as a primary key, the value "0" means that the object has no
primary key. It is not possible to save an object with the primary key
explicitly set to 0.
If we do not use Jdk 1.5, two and a half possible solutions come to my
mind:
1) Do not use primitives internally, but allow primitive getters and
setters. This will allow the user to read in a database row where null is
set for a primitive filed, but querying this field will rase an exception
(this is the correct behaviour in my eyes). This also will simplify
templates a little bit: there are few places where primitive columns are
treated differently, and the places where a key oubject is created from a
column will also be shorter.
Changing the internal representation will not be visible to end users: The
field itself is private and only accessible via its getters and setters.
The disadvantage of this approach is its slight performance impact of
boxing and unboxing every time.
2a) Disallow nullable for primitives and foreign keys. Disallow primitives
at all for primary keys.
2b) Disallow nullable for primary keys. Intoduce an extra boolean whether
a primary key is already set or not.
Personally, I'd prefer 1), because it is the simplest possible solution.
2a) is incompatible with the current implementation (no primitive primary
keys), and 2b is too complicated in my eyes.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org