Will Holcomb <[EMAIL PROTECTED]> writes: > On Sun, 10 Nov 2002, Walt Armour wrote: > > > We've worked around some polymorphism issues with the statics in > > BasePeer (see the recent thread "reasoning behind so many static methods > > in BasePeer") and one of the things we did in an intermediate layer was > > to dynamically build a Criteria by adding to it as setters are called on > > the OM object. > > That's a good way to do it and it seems like you could also use that to > cut down on the number of fields sent in. Some sort of function to tell if > a column has been set is still needed though. As it is, I can't tell if a > key hasn't been set or if it has the value of 0. > > I think that the statics in BasePeer need serious reconsideration. What I > am playing with and will see if I can get to work, is making the methods > in BasePeer non-static, but leaving the static methods in the generated > peer and send them to a static singleton. Most people are not calling the > methods on BasePeer anyhow, and so long as the methods are still static in > the generated peer I think that it will not break much code.
Everyone hates the statics in the Peer system. In the list archives, this has been discussed several times over the last couple years. IMHO, it would be best to get 3.0 out the door before any serious revamping is considered; Torque has been that way since The Beginning -- people can wait a while longer. My personal preference would probably be for the Peers to disappear entirely, absorbed into the business object layer. -- Daniel Rall <[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:turbine-torque-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:turbine-torque-dev-help@;jakarta.apache.org>
