> >If you want to spend the next few months/years designing, > >implementing, and maintaining your very own persistence mechanism > >embedded specifically into Torque, go ahead. But given that there > >are already viable, generic alternatives, I'd rather do that. > > There really isn't all that much to design if we're just > reimplementing the currently published API. What I want to do is > just fix the egregious performance problems in Torque so that the > basics of what is there now can be used. If you for instance > wanted to scrap the Criteria code and use some other better SQL > query abstraction, then that's a different story. But, if that's > the case, then start something new and don't call it Torque. I > don't want to change the overall design philosophy behind Torque, > I just want to make it work better.
If you could abstract a generic API for persistence, you could make the persistence mechanism pluggable. Big "if" here... Something else, related to Criteria: it is well known that the design of this class is really lacking, and makes it very difficult to compose complex criteria. Criterion was a good step forward, but this is definitely an area of Torque that could use some redesigning. -- Gonzalo A. Diethelm [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
