OJB is not considered a replacement/successor to torque. It is an alternative.
john mcnally On Thu, 2002-08-29 at 12:49, Russell Smyth wrote: > > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
