[Opensource] DBObject vs. JDBCDataObject [was dbobject.getTargetTable() deprecation [REALLY LONG WINDED :)]

[Michael Rimov]

At 10:45 AM 7/28/2003 -0700, you wrote:

>thanks, that gives me a broader perspective. I'm 100% OK with deprecating 
>the method.
>
>Let me ask a question that grows out of this discussion, just for 
>clarification.
>
>Here's what I understand so far about the new hierarchy:
>
>DataObject is the general superclass
>JDBCDataObject is a subclass for JDBC
>DBObject subclasses JDBCDataObject
>
>What is the purpose of DBObject relative to JDBCDataObject? In other 
>words, what parts of DBObject could not be put in either the general 
>DataObject or the less general JDBCDataObject?
>
>the Javadoc for  DBObject reflects its former mission, which is now 
>accomplished by its superclasses, it seems:

Larry,

So glad you asked! :)  The biggest suggestion is to read the paper I wrote 
about Expresso 6 design.  That would give you a better idea of the gist of 
what I would like to see in the long run.  Will it change?  BIG TIME! 
:)  But the goal of the article is still the same.

But let me just say this for those of us that don't have the time to go 
through the rambling design docs. :)

Currently I'm treating JDBCDataObject and DBObject as basically one and the 
same.  What it's allowed me to do is ascertain which variables and methods 
inside DBObject are dependent on one another.  I just move a method to the 
base class and see what errors pop up and I know what the interdependencies 
are.  It's helped tremendously for me to get into the first layer of what 
to scrape off of DBObject.

My next goal is to reduce the method count by:

-Eliminating Metadata calls:  Things like getTargetTable() etc.  If you 
notice, I have not yet designed any sort of SPI to help build the 
DataObjectMetaData....  that is still a 'todo' item, and will eventually 
eliminate probably another 20 functions from DBObject

-Move some methods to external utility classes.  For example, the 
algorithm: addIfNeeded and addOrUpdate are pretty easy to generalize to all 
the formats, so they could be rewritten in external utility classes in such 
a way that they take the base DataObject API as their arguments.  Possibly 
up to 10 more methods could be moved that way.

Once the method count is reduced, I will have a much easier time of saying, 
"A JDBC Object should do this...", "A base class DataObject should do 
this"... and answer some of my other questions such as factory methods etc.

So how does JDBCDataObject relate?  It will probably eventually replace 
DBObject as I further work on things.  But for the time being, it's serving 
as a bit-by-bit building block, so I can further study the DBObject "domain".

HTH!
                                                 -Mike