If you take the reflection concept one step further...
When you get to an object that would be serialized to the database (just
about every object besides a String, Date, BigDecimal, etc.), you can
continue the reflection by recursing into the object. So, if a person want
to CMP a Vector, you would recurse into it and store the
elementData[](recurse into this array also), elementCount, and
capacityIncrement values in a Hashtable.
I believe this would be generic, however you would bypass the equals()
method unnecessarily if the person actually implemented it.
I think the most generic approach would be the least valuable in this case.
jim
----- Original Message -----
From: Rickard �berg <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 23, 1999 10:13 AM
Subject: Re: Tuned DB update implementation strategies
James Cook wrote:
> In regard to the storing of original values...
>
> I posted a mechanism, a few days ago to this list, that we use to
accomplish
> this outside of the container. It simply uses reflection to store
attribute
> values in a hashtable. I'll make the following two assumptions.
But there is an important difference here: you are allowed to make
assumptions since you're essentially "rolling your own" CMP. A container
does not have this privilege. All it knows is that the fields to be
persisted comply with the EJB spec., which allows a lot, most notably
all serializable classes (see sec. 9.4.1). To be able to use this
technique, which certainly seems easiest to implement, one have to rely
on proper equals() implementations. Since the EJB1.1 spec. does not
mandate this, a EJB1.1 compliant container may not assume this.
And *that's* the problem.
There are practical approaches such as "fine, if you don't want to
implement equals() then don't use tuned dbms updates", which will
probably work fine in most cases. But it is not a generic approach.
So, my question was/is if there exists a (good) technique that works in
the generic case.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
