On Thu, 30 Nov 2006, Greg Monroe wrote:
Thomas Vandahl said:
Greg Monroe wrote:
Additionally, the generated record objects could make use
of this new base class to support things like isNull() on
primitives. We could also use this to track modified and
unmodified column values, which would be very useful (e.g.
updating tables without primary keys).
I'd throw primitives away completely. There is no advantage
in keeping them. Especially with JDK 1.5.
I think there's still benefit in having record objects with
primitive get/set field access methods. They are like the
static Peer methods, not the best way to do things, but they
make coding easier.
But the underlying storage could be Object based with conversion
occuring in the generated field methods. Even with these, the
underlying objects could still be access via the getBy/setBy
methods.
Of course, there would be a slight performance hit since the
conversion takes place each time the method is called rather
than at population time.
If we only use objects internally, this would make coding and templating
easier. I do not think the small performance overhead of object/primitive
conversion matters much nowadays.
If we use java 1.5, I'm not sure whether primitive accessors and setters
make sense at all (better create the cost of conversion on the user's
side, so he can take control over it)
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
