Torque -

[Paulo Silveira <Pa...@commworld.de>]

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: dlr@finemaltcoding.com [mailto:dlr@finemaltcoding.com]
Sent: Montag, 25. Februar 2002 04:17
To: Turbine Developers List
Subject: Re: Torque / Peers


Stephane Bailliez <st...@haht.com> 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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Torque -

[Christian Asmussen <kr...@kriconet.com.br>]

I have been playing a little around with castorXNL in conjunction with
torque.  I wrote a mapping for the app-schema.xml so that I can load it as
a castor object.  Ie 
TorqueTable tbl;
tbl.getColumns();
tbl.getPrimaryKeys(); 
etc.

If this structure existed, it would be possible to have all that what
Paulo mentioned in several directions.  Like:

introspecting the database itself to create project-schema.xml
introspecting the available classes to create xml and classes
or using the common shema.xml to create the db and classes

Then when someone is writing an IDE they could use this too.



On Mon, 25 Feb 2002, Paulo Silveira wrote:

> 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: dlr@finemaltcoding.com [mailto:dlr@finemaltcoding.com]
> Sent: Montag, 25. Februar 2002 04:17
> To: Turbine Developers List
> Subject: Re: Torque / Peers
> 
> 
> Stephane Bailliez <st...@haht.com> 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>