It looks like you and Fedor had similar ideas. I wonder if maybe we should do something like this:
Keep the current classes for backwards compatibility, but start reworking these classes to start using the crossdb framework. It looks like these classes could use crossdb to get the same results. At the same time, start deprecating these things and start moving towards crossdb usage which should do away with most of the limitations and problems that I've been reading about with the current Criterion. Travis ---- Original Message ---- From: Eric Dobbs <[EMAIL PROTECTED]> Sent: 2002-04-24 To: Turbine Torque Developers List <[EMAIL PROTECTED]> Subject: Re: Torque subproject - crossdb Welcome! On Wednesday, April 24, 2002, at 10:37 AM, [EMAIL PROTECTED] wrote: > Just to fill you in on what this is about, I submitted a proposal to > the jakarta general list and you can read the discussions here: > http://www.mail-archive.com/[email protected]/ > > But basically, I am wanting to bring the crossdb project to Jakarta and > making it a subproject of Torque seems to be a good idea because of the > relations. > > So I don't know how this works, but I guess it would be up to you guys? I read some of the discussion on general yesterday and briefly browsed through the code. About a year ago Fedor and I discussed at length the need for a new query model, but we never settled our disagreements and both dropped the issue. crossdb looks to be similar in many respects to various things Fedor and I proposed in our debate. Below are links to Fedor's and my code and links into the debate. The code and discussion might be worth a little of your attention so you can see what we've discussed before. I wouldn't suggest you read all of it (that would probably be pretty boring 8^). Fedor's proposed code is here: <http://cvs.apache.org/viewcvs/jakarta-turbine- torque/proposals/fedor/nqm/> And mine is here: <http://cvs.apache.org/viewcvs/jakarta-turbine- torque/proposals/eric/statement/> Discussion about the options... The last option I presented is here: <http://www.mail-archive.com/turbine- dev%40jakarta.apache.org/msg01147.html> And this search should hit most of our debate: <http://www.mail-archive.com/cgi- bin/htsearch?config=turbine- dev_jakarta_apache_org&words=fedor+eric+new+query+model> Your code has an immediate advantage because it's in use whereas Fedor's and my code has collected lots of dust. And I just noticed that Jeff Schnitzer has suggested on turbine-torque-user an api from RogueWave as a model: <http://www.roguewave.fr/support/docs/dbtug/4-5.cfm#451> The fact that RogueWave has been making some money on an api for abstracting sql generation lends support to our argument on general that there's value in such a project. Here's a jumpstart into the Torque objects that deal with SQL generation: org.apache.torque.util.BasePeer org.apache.torque.util.SqlExpression org.apache.torque.util.Criteria org.apache.torque.adaptor.DB* And village is also used in BasePeer: http://share.whichever.com/village I think crossdb fits somewhere in there. But I haven't given it enough attention just yet to know exactly where. BasePeer and Criteria are used extensively by Torque applications. So those APIs need to be preserved. I mostly loathe the Criteria object, but there's no quick escape. I haven't actually looked recently, but I suspect that SqlExpression and the adaptors could be replaced. Dan has cautioned in the past that the database adaptors serve other purposes besides handling the dialects of different databases. So those uses would need to be factored out of the adaptors before replacing them. -Eric -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
