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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
