I guess the real question is: What do we mean by "Throw away primitives"?
There are three main area I think we are talking about: The record objects, the criteria objects, and overall runablity / compilability. On the record side of things, I can't see that it's a big problem to keep supporting the primitive XML option. Let the application designer decided whether to use primitive or objects via this. It's only a VERY small set of template code that's required to create primitive getter/setters. Everything internally can be object or not. The criteria object is a slightly different problem. On one hand, I can see that going to object only would simplify the multitude of add methods. But it would cause a lot of code to be re-written. It may be time to dust off my VERY rough pass at creating a criteria API that Thomas T and I kicked around a LONG time ago. This might be useful to have a "deprecated but works like the original" criteria and a "new improved object only" criteria. Then let the developer choose (with an emphasis on the DEPRECATED fact...) As to the compilablity / runablity issues... Personally, I'd like Torque generated code to be compilable/runnable under 1.4. There are still a lot of folks "stuck" at this level for various reasons. With Java going GPL, I suspect this number will be dropping.. but probably not too fast. But the hard limit is that it definitely needs to be RUNNABLE under 1.4. I.e., you need 1.5 to create the OM layer but not run it. But as people have pointed out, there is a whole bunch of 'gotchas' to look out for with this scenario. > -----Original Message----- > From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 30, 2006 6:21 PM > To: [email protected] > Subject: Re: Torque 4.0 plan > > Thomas Vandahl <[EMAIL PROTECTED]> writes: > > >Greg Monroe wrote: > > >> Additionally, the generated record objects could make use > >> of this new base class to support things like isNull() on > >> primitives. We could also use this to track modified and > >> unmodified column values, which would be very useful (e.g. > >> updating tables without primary keys). > > >I'd throw primitives away completely. There is no advantage > in keeping > >them. Especially with JDK 1.5. > > You lose all the J2EE 1.4 people. J2EE will be (in the real world) on > JDK 1.4 for a long time. > > There are tools like Retroweaver but throwing primitive support out is > IMHO too early. Hibernate did and people still complain about it. > > Best regards > Henning > > > > -- > Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, > 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person > Open Source Consulting, Development, Design | Velocity - Turbine guy > > "Save the cheerleader. Save the world." > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Duke CE Privacy Statement Please be advised that this e-mail and any files transmitted with it are confidential communication or may otherwise be privileged or confidential and are intended solely for the individual or entity to whom they are addressed. If you are not the intended recipient you may not rely on the contents of this email or any attachments, and we ask that you please not read, copy or retransmit this communication, but reply to the sender and destroy the email, its contents, and all copies thereof immediately. Any unauthorized dissemination, distribution or copying of this communication is strictly prohibited. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
