[Opensource] dbobject.getTargetTable() deprecation

[larry hamel]

Okay, thanks for the clarification.

so DBObject subclasses JDBCDataObject, and thereby has the inherited method

    public final JDBCObjectMetaData getJDBCMetaData() {
        return (JDBCObjectMetaData)getMetaData();
    }

Will this break for DBobjects which are not using JDBC?

Anyway, this is exactly the kind of convenience that I'm looking for.  could we redefine getTargetTable() as

        public String getTargetTable()
            throws DBException {
        return getJDBCMetaData().getTargetTable();
    }

??

Whatever protection is necessary to allow getJDBCMetaData() to be accessible from any DBobject could be reused for getTargetTable(), no?  shall we introduce some NotImplemented exception, testing with instanceof?

Again, I think that generalizing DBobject is a step in the right direction, and the goal here is balancing, being both general and also supportive of the 80% JDBC case.

larry


At 12:14 AM 7/25/2003, you wrote:
>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
>