db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Monroe" <Greg.Mon...@DukeCE.com>
Subject Village meta data calls (Was: Will migrating from 3.0 to 3.3 help me?)
Date Thu, 02 Oct 2008 15:54:38 GMT
I'm in agreement that we need to fix this... but on the other hand, 
it's been part of Torque since day one and the performance hit hasn't
motivated anyone into fixing yet... 8).

A couple of things to note about the meta data calls (from the memory 
of wading thru the Village code in that past and may not be fully 
accurate...).  

First, although Torque may not use the Column object directly, the 
Village internals for doing updates and inserts use it a lot.  Torque 
currently uses Village calls to do these actions.

Second, we may not want/be able to eliminate all calls to the meta-data.
If my memory is correct, Village checks the meta data in order to 
properly convert the supplied value into the format the database 
expects.  

IMHO, I think this has been secretly helpful in automatically mapping
between Torque's XML schema and the native columns.  Especially when
the tables have not been created via Torque.  It means you just have 
to find a data type that's "close" to the native one and then Village
and JDBC maps it correctly to and from Torque objects.

If we don't want to lose this functionality, we still need to do some
checking as to what the underlying column type is.  I'm thinking that
this information should get added to the ColumnMap object and the 
initialization routines changed to make the call to get the Meta
data.  This would cache the meta data, cut the meta data requests to
just a few, and still maintain the underlying Village flexibility.

Just some quick thoughts on this.  Take them or leave them.

Greg

> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au]
> 
> I am not telling you anything you don't already know, but it sure is
> interesting to see this myself.
> 
> Looking at torque, the only references to
> com.workingdogs.village.Column
> (directly and via c.w.v.Schema) are in
org.apache.torque.util.BasePeer.
> Usage would appear to be limited to retrieving the name of the column
> (via Column) and the number of columns (via Schema).
> 
> So it looks to me like we should look at producing a version of
Village
> that skips retrieving unnecessary metadata.  For people using JDBC
> drivers that implement the metadata retrieval methods this will result
> in a performance improvement significantly larger than any other
> refactoring we might be considering for 4.0 and potentially this could
> be substituted into to a 3.3.1 release with just an updated pom.
> 
> I have a couple of dozen other things on my plate right now, but if
> someone else cares enough to verify my analysis I don't think it will
> be
> too difficult to achieve something positive out of this.
> 
> Scott
> 
DukeCE 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-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org


Mime
View raw message