I forgot something: We've implemented a "working" and easy way to use Aliases with JOINs. This is necessary if you join a table twice. And the "Add full support for views" is something that would be very useful.
T. > -----Ursprüngliche Nachricht----- > Von: Greg Monroe [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 30. November 2006 17:29 > An: Apache Torque Developers List > Betreff: RE: Torque 4.0 plan > > > > Thomas Fischer said: > > > > Now that the first Torque RC is outit is time to think about > > what we'd like to do as next version. Personally, I'd like > > to propose the following: > > > > Can't complain about that list. Only +0 items I'd list > would be on the Maven 2 conversion and the generic generator. > > > - Switch to Maven 2 as build system. Maven 2 has much better > > multiproject support than Maven 1, so building will be > > easier. > > My +0 for Maven 2 is based on the little bit I dug into it > for the add-on stuff. It seemed to add a lot of complication > and extra more effort to do thing outside the "Maven 2 norm" > that was fairly easy in 1. IMHO, build systems should take a > minimum of time away from your development time, not become > a subproject of it's own. > > But to be fair, it could be I just didn't take the time to > learn it well enough. But if someone else is doing the work ;) > who am I to complain...lol > > > - Make the generator more generic. I'd like to turn the > > generator into a generic code generation tool > > I'm +0 on the idea of the generic generator. I can see the > worth in this, but I'm not sure it's a core Torque thing. > It seems like this should be like Torque and Turbine, some > of the ground work layed here but with a plan to split it > off into a separate project. Plus, is this competing with > Velocity/Texen? None of this is a show stopper, just thoughts > for fine tuning the proposal. > > Here's some idea's I'll throw in the ring: > > Better support for non-record type queries. I.e., the > stuff people do with executeQuery / Village Records. Queries > of this type that come to mind are: > > - Optimized Join queries that return data from multiple > tables (for creating master lists). > > - Queries with functions. > > To support this and also assist in the Village exorcism, > I'd propose making the BaseObject an actual storage > implimentation, like Village Record or ResultsSet. Internally > the data would be stored as objects in OrderedMap with the > getBy/setBy methods being the BaseObject access points. > > This would allow executeQuery to return a list of BaseObject > records. > > 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). > > Take a serious look at DDLUtils integration, and maybe do > a little encouraging to get that project to do a release/ > Maven repo set up. > > Some stuff that may be V4.5 features but might be nice to > start planning for: > > Add full support for views, since most of the common DBs > support them. E.g., a way to define them in the DTD, > support for creation, etc. > > Look at being able to generate object level "views". E.g., > I'm always creating "wrapper" objects that are based on > subsets of data from two or more related tables, with access, > load, and store methods. I'm thinking this would be a way > to define business objects via XML and have them generated. > > Support for "lazy" record object population. Sometimes it's > better to retrieve a set of partially filled objects (e.g. > doing a master list), and only totally fill the object when > needed. Adding an isLoaded option to the isNull, isModified, > column level tracking would make this fairly easy. > > A GUID based idBroker method to autogenerate keys without > needing access to a table. > > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
