db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Monroe" <Greg.Mon...@DukeCE.com>
Subject RE: Plan to enhance Database Mapping info
Date Thu, 04 May 2006 16:21:41 GMT

> -----Original Message-----
> From: Thomas Fischer [mailto:tfischer@apache.org] 
> On Fri, 28 Apr 2006, Greg Monroe wrote:
> >
> > So the method for fully initializing a Torque DatabaseMap
> > would be:
> >
> >  DatabaseMap map = Torque.getDatabaseMap(DBName);
> >  map.initialize();
> >

> Thomas F wrote:
> I have some comments here, which are not addessed by your 
> code above.
> 1) So far, Torque has been supporting accessing several 
> databases at the same time. Your code above only cares for 
> the default db, not for others that might be around.

I think there is some confusion here... I'm talking about
org.apache.torque.map.DatabaseMap that is used as the "root"
object for each schema Map stored in the Database object 
instances that TorqueInstance maintains for each DB name.

The getDatabaseMap methods return the DatabaseMap instance 
object for the associate DB schema name. So this code 
should be multi DB safe.

In addition, Henning's code to generated the initialization 
classes and my code from properties files all have the DB 
name embedded in their names. E.g, The "bookstore" schema 
will generate BookstoreMapInit.java and 
torque-bookstore-map-init.properties, while the "test" 
schema will generate TestMapInit.Java... and so on.  These 
allow for multiple DB schema's with only the same "schema 
names must be unique" restriction that Torque currently has.

> 2) Make sure everything you do is also working if you have 
> several schema files for the same database as well as several 
> schema files for different databases around (the last case is 
> linked to comment 1)

Not a problem, I've actually finally set up a Torque Maven test
bed here (hence the spat of MSSQL related Test issues in JIRA).
I'll include a test case for this in my code submission.

> 3) When this was discussed last year, some people cared about
> startup time, which could be long for large schema files. Make
> sure one can still use the old way to initialize the database 
> Map. Probably the  best way to  do this would be to add a 
> configuration property.

Actually, my thinking on this is that no changes will need to 
be made to the init processess at all.  If your application
logic needs a fully populated Map, then the app code should
call the initialize() method.  It only populates the map once, 
so it's not a performance hit to call it multiple times.

If you need to initialize everything, just init Torque, then
use getDatabases() to work from there.  Once again, an 
application specific but generic method of doing this.

> 4) Make sure that the runtime still works without any 
> generated classes being around.

That's a sub-reason for the above thoughts.  The only place
it fails is if the application specifically calls the 
initialize() code. And this code wraps all the possible
errors due to parts in TorqueExceptions with specific

If you don't care about ensuring all map info is populated 
in your code, you don't get effected. Life works exactly 
the same, with lazy map population as needed.

If you do care, since you are messing about with reflection 
type of coding, your code should add application specific 
safe guards. Just like you should when using the Java 
reflection methods.

FYI, I will add a ToDo to beef up the JavaDocs in this area
and this is another good test case to add.

> > You're right. Especially when you add in Thomas V.'s
> > comments about Managers.  A re-write of the coding goal
> > would be:
> >
> > Make sure that given any Torque OM, Peer, Manager, Map,
> > etc. class, even if passed in as a "Base" object, you
> > can find the others in some way.  This should:
> >
> > - add a minimum of convenience methods.
> > - be balanced against, having to have application code
> >  dynamically create classes, etc.  E.g., Don't just
> >  pass back a class name string.
> Hm, not convinced about that. I have another belief in this 
> matter, which is "No class should know about any other class, 
> unless it has to".

OK, this is getting too "complicated".  I'll limit any additions
in this area to stuff I need for XML export/import coding.  These 
will have application backed need.

> Why should the database map care about how the database is 
> accessed (i.e. the peer classes) and the database objects ? 
> It is just a map of the structure of the database and has no 
> need to access teh database in any way.

It's basically the same issue/reason that JDBC drivers support 
access to SQL Meta data. A high percent of applications don't
need this.  But sometimes, if it's available, an application 
can really use it.  (Like Torque's jcbc to schema Task...)

If you are starting from a generic set of information (e.g. 
XML parsed set of strings), you need to figure out how to map 
this into the OM layer objects and decisions made if this
information is to be Inserted or Updated.  

> Also, because of Torque's support of inheritance in data 
> objects, there is no 1:1 mapping between database tables and 
> the database object classes. Several database object classes 
> can live in one database table. So there is no 1:1 mapping 
> between peer / map classes on the one side and database 
> objects on the other. A data object class can only have one 
> peer, but a peer can be used by more than one data object class.

I agree. The map information is roughly like the SQL Meta data.
Just like the SQL Meta data doesn't expose all the nasty details 
that ancient index access method databased needed, the Map info
is there to describe the OM layer objects and a minimum of 
SQL connection information (like table names and column names).

I'm not advocating this... but if we wanted to be really full 
featured, the map structures should contain enough information 
for the schema XML to be recreated from it.  8) That's just
a thought for the future.

> > .. some excellent discussion on the evils of static
> > methods removed...
> >
> > All good points, I'll have to put some more thought into
> > how to meet the above goal. (unless vetoed.)  Just to
> > float a top of mind idea...
> >
> > Should there be some set of instance methods in the
> > *Peer classes that match similar static methods?
> That would clutter the class too much in my opinion.

Not surprised.. I'm +1 on this too.

> > Or maybe there should be a generated *PeerInstance class
> > (like TorqueInstance) with matching methods?
> That would be better. So one still has the convenience of the static
> methods and get the benefits of object inheritance.

With the scope re-definition of only adding methods I need, 
I'll put this down as a future enhancement project.  Unless
someone else wants to volunteer... 8)

> As far as I understand it, ListOrderedMap is equivalent to 
> LinkedHashMap. However, ListOrderedMap works with java 1.3, 
> whereas LinkedHashMap does not. So far the runtime has been 
> java 1.3 compatible, so please use ListOrderedMap.

[ Writes under his breath with big 8) on face] 
Grumble grumble... code done..grumble..have to rewrite.. 
grumble.. supporting dinosaurs... grumble...grumble
[ big sigh ]

OK, I'll use that.  Just out of curiosity do we know if all 
the dependent jar's are 1.3 complient as well? Just because 
Torque's code compiles under 1.3 doesn't mean the support 
code is OK with it at runtime.

> As far as I know, all of the "modern" map implementations need to be 
> wrapped in a synchronizedMap to be synchronized.

Yes, and any iteration objects retrieve from then need to be 
synchronized on the Collection object as well.. (is now..and
[grumble] rewrite will be to)

> Sorry, I misunderstood you. I thought you were proposing to create a 
> method which retrieves the name of the database. The javaName 
> property sounds good.


> > Another way would be to totally re-write the Template to just
> > use Set/Get methods and drop using the old add methods. Then mark
> > the add methods as deprecated.
> Now I understand what you want to do. I like the second way better 
> (that is the one you proposed at first, as I understand it). 
> This will 
> also ease reading of MapBuilder.vm.

Duke CE Privacy Statement
Please be advised that this e-mail and any files transmitted with it are confidential communication
or may otherwise be privileged or confidential and are intended solely for the individual
or entity to whom they are addressed.  If you are not the intended recipient you may not rely
on the contents of this email or any attachments, and we ask that you  please not read, copy
or retransmit this communication, but reply to the sender and destroy the email, its contents,
and all copies thereof immediately.  Any unauthorized dissemination, distribution or copying
of this communication is strictly prohibited.

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

View raw message