Thomas Vandahl wrote:
> On 21.06.11 22:45, Thomas Fox wrote:
> > But as I said, the methods can be turned off via a generation option,
and
> > the default is that the methods are generated. If you are more happy
with
> > the default that the methods are not generated, I can easily change it.
>
> I have no problem with the approach. From what I see, it's more a
> documentation issue and maybe some cleanup of the generator parameters.
> We need to explain the different ways of getting related objects and
> give it to the user to decide which one (or more) to use. That would
> mean to have similar switches for the getXXXs() methods (currently
> "complexObjectModel" IIRC and the doSelectJoin...() methods
> ("complexObjectModel"?).
I am fine with that. So I suggest to do the following
- change the default for generating the filler methods to false so that the
fillers are not generated by default
- add a generation parameter to turn off the generation of the
doSelectJoinSomething methods
independently of the complexObjectModel option (setting complexObjectModel
to false will turn off far too much). Currently the doSelectJoinSomething
methods are created as protected methods in order not to bloat the public
API. Do we want to keep this as it is or do we want to set the new option
defaulting to false but the method signature to public ?
- add a section in the runtime documentation, section reading from the
database, on the different methods to populate foreign key relations.
Is that ok with everyone ?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org
For additional commands, e-mail: torque-dev-h...@db.apache.org
