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