Using torque, we have a XML schema file, and when it is parsed, some classes are created.
What if we had the classes, and then, in run-time, and using the reflection API, we create the SQL statements according to the members of the class. Of course all members must implement SqlField or something, then we know if it is a varchar, an int, a primary key and so on. Torque is an incredible tool, but I would like to know if a tool like this would be good. Remember that I am not talking about efficiency, just about usage. Cuz it would really be easier, and when you change something in your db, you just need to add a new field in you extends Table class. Thanks Paulo -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Montag, 25. Februar 2002 04:17 To: Turbine Developers List Subject: Re: Torque / Peers Stephane Bailliez <[EMAIL PROTECTED]> writes: > Hello, > > I would appreciate some enlightments about the rational of having > static methods on peers in Torque. > > With time, I think that a better approach would be to have singleton > on these instances to benefit from an interface and method overriding > rather than method hiding. We should be able to get the singleton peer > from the object via a static getPeer method or such. > > The main problem right now, is that we cannot design a generic set of > operation on Peers. (or at least I'm unable to do so) Say I have A and > B and each of them has a customized peer APeer, BPeer which method > doSelect hide the base one because I want to add some > precondition/postcondition. > > Now say I want to perform a batch selection of A and B via a generic > select operation, I would use instances of APeer and BPeer in an > operation that takes a BasePeer[] argument. Now due to method hiding > I'm in trouble to perform the appropriate > doSelect() on APeer and BPeer. How to call the right static method ? > yay ! Using reflection is the only option AFAIK. > > Of course at some points it is problematic for retrieveByPK signatures > since Java as of now does not allow covariant return type (JDK 1.5 I'm > afraid). So these methods must return an Object. > > Any stupid things in what I'm saying ? :o) Stephane, this has been discussed to death (see the archives). Everyone is in favor of moving Torque away from statics. Dan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
