db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <fisc...@seitenbau.net>
Subject RE: Plan to enhance Database Mapping info
Date Thu, 27 Apr 2006 15:49:35 GMT
"Greg Monroe" <Greg.Monroe@DukeCE.com> schrieb am 26.04.2006 20:32:28:

> I've mentioned several times in the past that I planned to take
> Henning's Mapbuilder-init proposal code he submitted 2+ years ago
> and update it to work with the latest version. Well, I've finally
> found some time to do this.
>
> However, in reviewing the code prior to doing this, I can see some
> area's of code that could be easily modified to make the DB Map info
> more useful.  But before I get too far into it, I thought I'd lay out
> my plan and see what others think about this.
>
> First, the basic thing I'm looking to improve is to make it easier to
> do dynamic coding using introspection.  Some examples of how this might
> be used:
>
> - Mapping an XML file that uses the Torque generated DTD into object.
>
> - Having generic methods that use BaseObject or BasePeer arguments and
>   decide to what to do based on introspection.
>
> Both of these are things people have asked/talked about in the mailing
> list (OK, the XML need is mine 8) ).
>
> Anyway, here's what I plan to do:
>
> 1) Create a way that the full DB map can be initialized based on
> Henning's proposal.  This would involve the <DB>Init class (ala H)
> and couple of new Torque/TorqueInstance methods like:
>
>   Torque.getDatabaseMap( String DbName, boolean init )
>
> If you need to do full Introspection on all tables, just get your
> DB Map with init set to true. (Mostly done)

Sounds good. However, can you be more specific about how you would link the
Torque object to the generated model ? Referencing a generated class from
the runtime is a bad idea in my opinion. And I do not see any other clean
possibility.... I'd rather only generate a class which you then call to
load all TableMaps.

> 2) Modify the Table OM, Peer, and Map objects to include symetrical
> methods so that any object can easily get the other two (via public
> methods.)  E.g., Peer currently has getOmClass() and getTableMap()
> methods.  But getTableMap() is protected and should be made public.
> The Table OM class has a getPeer() method, but probably should have
> a getTableMap() convienience/symetrical method.  TableMap needs
> getOmClass() and getPeer() methods.

- Making Peer's getTableMap public is ok with me.
- I am not convinced about the OM classes' getTableMap() method. Why can't
you use the Peer's getTableMap ? Convenience methods are added quickly, but
removing them is nearly impossible. Remember the cluttered criteria class.
- I am also not convinced about the Map's getOmClass() method, for the same
reason.
I'm definitely -1 on adding a getPeer() method to the OM class. Remember
that all Peer methods are static: I'm not even convinced that the getPeer()
method makes sense at all, because as far as I know, it is determined at
compile time which overloaded static methods are used. So if you write

SomeBaseObject someBaseObject = getSomeBaseObjectFromSomewhere();
BasePeer peer = someBaseObject.getPeer();
peer.doSelect();

then BasePeer's doSelect method is called and not SomePeer's doSelect
method, even if someBaseObject.getPeer() returns an instance of
SomeBasePeer.

Also if it was possible

BaseObject someBaseObject = getSomeBaseObjectFromSomewhere();
someBaseObject.getPeer().doSelect();

(which method will be called is determined at the copile time type of
someBaseObject)

Only if you do

someBaseObject.getPeer().doSelect();

you will call SomeBasePeer's doSelect method and not BasePeer's select
method, but if you do this you also have written

SomeBasePeer.doSelect();

In my opinion, this is very confusing and one should not use the getPeer()
methods at all.

>
> In addition, there should be "Not implemented" stubs for these
> methods in the BaseObject and BasePeer classes so that they can be
> used when Subclasses are passed via the Superclass type.

No, definitely not for the Peer classes (see above). Java will not allow a
getPeer() method which returns a BasePeer in BaseObject and returns
BaseSomethingPeer in BaseSomethingObject. And if you change all the
signatures to BasePeer, then all the static getPeer methods are useless.
Adding an static getTableMap() method is also useless (Java does not allow
abstract static methods, for good reason.)

>
> 3) Fix some misc Mapping issues like TableMap using a Hash table
> which looses the XML ordering of columns. (Already done...)

How ist this done ? Using commons-collection's ListOrderedMap ? That would
be ok with me.

> adding
> a JavaName property to the TableMap so that the Key used in the
> DatabaseMap can be gotten from the object;

Not so sure about this one. Why not use TableMap's getDatabaseMap() method
and ask the Database map for its name ?

> and maybe redo-ing the
> TableMap.vm to use Column.set.. functions rather than all the add
> methods which are a pain to modify each time you need to add a
> new property.

I'm not sure what you mean by this. Can you be more specific please ?

    Thomas


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message