> > > 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 thought about using the Criteria for this (but only for a moment) before deciding it would be way too much of a pain. Yeah, some approach would be needed for this. Luckily for us at the moment we don't have a pressing need to see if a particular field has been set. > > 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. > That would be nice. BTW, you mentioned in the original patch post that it was for RC2. Did you mean the CVS version? I haven't seen any mention of RC2 coming out yet (and I'm praying it's not as painful as RC1). -- 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>
