> Ok, for me, that's ok. This method is more straigth.
>
> I will modify the peer template to suit the method we explained
> (createObject()...).
Thanks! Great. I still can not get newtorque to work for me (empty output).
I believe you had similar problems - can you tell me how fixed it (in
private e-mail)?
>
> Another feature to add would be the readOnly="true" for tables. That
allows
> torque to generate or not the doInsert, doUpdate, doDelete method. I'm
> thinking about tables contains list of countries, states and other static
> information.
> Do I add this feature ??
Nice feature, Not sure how high priority it has...
BTW, what are you going to do with doInsert and doUpdate? Override them so
that they simply do nothing or throw ReadOnlyException or something? Or
create a ReadOnlyPeer (BasePeer's brother) which does not have those methods
at all?
> I already add the autoincrement value in the column class. I also have
> modified the map template in the way that it use the database
autoincrement
> if it is set to true.
did you test it on DBs with sequences?
> I will propose you my modification when every thing (or a big part) will
be
> done.
Cool!
> > > I believe you misunderstood me. Here is another explanation:
> > >
> > > Generated AddressPeer should look like this:
> > > ----
> > > public class AddressPeer extends BasePeer{
> > > ....
> > > protected Address createObject()
> > > {
> > > return new Address();
> > > }
> > >
> > > ....
> > > public Vector doSelect(...)
> > > {
> > > ....
> > > - new Address();
> > > + createObject();
> > > }
> > > -----
> > >
> > > MyAddressPeer would look smth like:
> > > -----
> > > public class MyAddressPeer extends AddressPeer
> > > {
> > > ....
> > > protected Address createObject()
> > > {
> > > return new MyAddress();
> > > }
> > > }
> > > ---
> > >
> > > this way you do not need to edit generated AddressPeer and if you
> regenerate
> > > AddressPeer all your changes (which you made in MyAddressPeer) won't
go
> > > away.
> > >
> > > Makes more sense?
> > >
> >
> > Makes a whole lot more sense :-)
> >
> > I think maybe we should go with this approach. It allows you to check
at
> compile
> > time if the objects are compatible (createObject() has to return the
> derived
> > object). With doSelect (Criteria, Classname) you might wind up with a
> nasty
> > ClassCastException you did not bargain on.
> >
> > Any other thoughts on this?
> >
> > ~ Leon
> >
> >
> >
> > ------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> > Problems?: [EMAIL PROTECTED]
> >
>
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
>
fedor.
_______________________________________________________
Say Bye to Slow Internet!
http://www.home.com/xinbox/signup.html
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
