[Opensource] dbobject.getTargetTable() deprecation

[Michael Rimov]

At 11:52 PM 7/23/2003 -0700, you wrote:
>ok, it appears that this cast is required
>
>    ((JDBCObjectMetaData)myobject.getMetaData()).getTargetTable()
>
>and while I understand that the goal is to abstract away from the JDBC 
>database to support other persistence methods, I'm worried that we are 
>being inconsiderate. There are over 50 calls to getTargetTable() in core 
>Expresso alone, and I think the "80% case" for Expresso users is a case 
>where they use a database via JDBC. Using the 80/20 rule, it would be nice 
>to accommodate such use, and make it easy to find out what table is 
>associated with a database object.
>
>Is there a way we can keep DBObject.getTargetTable() or something similar 
>as a convenience method?
>
>For all persistence methods under consideration (JNDI? others?), is there 
>something roughly equivalent to the table name? Could we declare an 
>interface method and have subclasses implement it?

I've been thinking about this for a bit.  One of our goals is to let folks 
benefit from high levels of abstraction but get to the lowerlevel guts as 
needed.  Because of that, the DataObject API, is minimalistic to the ends 
of extensibility and not necessarily convenience.

If you look at the usage patterns, getTargetTable() is used primarily 
within low-level 'in-DBObject' methods.  So you know you are dealing with a 
particular meaning like this.

Since a cast is awkward, all classes deriving from JDBCDataObject [ex: 
DBObjects] provide a getJDBCMetaData() in addition to getMetaData() so that 
folks can get JDBC specific info such as tables without the cast.  This 
way, folks dealing below the dataobject interface level [is inside the 
interface, ie low level writer] can still get the 'ease of writing' 
benefits, but it doesn't bloat the minimalistic API with JDBC specific 
stuff.  I agree that getTargetTable() could technically be considered 
something more generic in many ways, but consider for example the following 
possibilities for DataObject implementations:

Entity EJB - sure there's a table buried there but IIRC the programmer 
doesn't have access to that knowledge.

Database Joins - JoinedDataObject, while expecting JDBC-based objects on 
its internals, wouldn't necessarily have a decent-meaning return value for 
getTargetTable()

Now I'm pretty tired right now so I may be missing it.  But would 
getJDBCMetaData() as a convenience function for all classes derived from 
JDBCDataObject fulfill your needs as a compromise for now?  [Of course, if 
somebody else comes up with a better idea, PLEASE let me know :) ]

                                                         -Mike