> I'd like to do that refactoring in v4, assuming it happens (OJB lurks > ever present), and so I'm thinking this TorqueRuntimeException will be > something we can easily implement in v4 and with clean slate.
I've seen several mentions of OJB in the context of possible replacement/ successor to torque. I would like to stick my nose in here and make the statement that this should not be so - in my view, the products have different, though related, goals, or at least they could. In the view of the project for which we are planning/considering torque OJB and related tools such as Castor, JDO, etc, are aimed at persisting java objects to databases. Our use, and one that torque fits much better than OJB style tools, is to give Java programs access to database data that preexists the program. In other words, torque becomes a way to "javaize" a database. Our way of looking at this was that OJB style tools were for persisting java objects, in projects built from the java/application side down. Torque really shines when you are working from the database out, and need to objectize an existing database. In short, I hope that v4 and beyond will continue, as there will be java projects based on existing databases for years (possibly decades) to come. ok, back off of my soapbox now.... Russell Smyth -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
