> > You do not have to use an O/R layer that abstracts you away from the > > database you are using so much that it limits your ability to use the > > DB's functionality in something resembling a db-natural way. > > That is like trying to argue that using ECS is the way to write HTML.
Sometimes it is. > > While these may not be accurate summaries, I hope you now do see that > > CrossDB and Torque are not, in the majority of use cases, alternatives > > to one another. > > I'm sorry. I don't see that. Torque can do everything crossdb can do and > more. O/R mappers are not always appropriate. For example, in torque's case, when you are dealing with an existing database that was not generated by torque and does not have a structure that is appropriate to O/R mapping. I can see that in such a case having a mechanism to code SQL in a cross database way could be useful. There is room for tools of both sorts. Different levels of database abstraction are appropriate for different use cases. Hence, Village. (No stance on whether this should be a Jakarta project is implied by this message). -- jt -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
