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:[EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
