TorqueFuture

Torque Future

This page is intended to be a white board of ideas where to go for the next Torque major release. Don't expect everything written here to show up at once. I plan to use this page to poll for opinions on where to focus development in 2005. -- Henning

General

• Better documentation from the beginning. Maybe drop xdoc in favor of an easier to use format? (tfischer)

Torque Runtime

• Get rid of the static Peer classes. (hps)

• Get rid of Village. (hps,tfischer)

• General SQL schema (database namespace) support. (hps,tfischer)

• Defined datatypes for SQL columns and tables. (hps,tfischer)

• Introduce a some sort of "handle" onto a data source / table collection, allowing things like defined initialization, setting default parameters (similar to Hibernate Session?) (hps)

• Move functionality from the generated Peer and Object classes back into the runtime. (hps)

• Build a pluggable criteria system using a generator (connected to the "handle" object to create a criteria and an evaluation method to get the query / select string) (hps)

• (Maybe) split up the Criteria into an Insert / Select / Delete criteria (hps,tfischer)

• Build a unified Transaction system, which is able to use different transaction types thus allowing the usage of transactions managed by a container (hps)

• Keep the "simple" approach that made Torque fast and versatile: Don't try to rebuild Hibernate. No generic object -> SQL mapper, just a table schema representation in SQL (hps,tfischer)

• No implicit caching (maybe pluggable). Use JCS? (hps,tfischer)

• Improve handling of 1:n relations: Add support for deleting related objects (tfischer)

• (Maybe) handle n:m relations automatically ? (tfischer)

• add support for "forcing" developers to use transactions (e.g. no background read, no save methods without connection arguments). Use a switch in the configuration for this. (tfischer)

• look into how related objects can be linked tighter, but retain the current save-through behaviour. Perhaps be able to modify save-through on runtime ? (tfischer)

• Have TorqueInit() search the classpath for its initialisation file, just as ResourceBundle.getBundle() does instead of using an absolute path name. (RM)

Torque Code generator

• Start looking into commons-sql, once is has been transferred to the DB Project. Start replacing the SQL part of Code generation with the commons-sql generator, making it compatible and exchangeable with OJB (hps)

• Examine ways to generate the Class sources with this project (hps)

• Allow multiple OM schemata to be generated, allowing one installed torque generator to be used for multiple project with different runtime levels (-- Henning: I have a patch for this). (hps)

• Get rid of Texen? Maybe go XSLT? Use some different templating technique (while Velocity and Texen do a reasonably good job, their error reporting really lacks. Integration of the engine into other projects is also not really intuitive). (hps)

• Split the OM classes for tables into two layers: a base layer that is a pure value bean with just the user-declared fields and appropriate getters and setters, and a derived layer (equivalent to the existing BaseXXX classes) that has all the supplementary fields for foreign keys, and all the logic. There reason is that I want to be able to transmit DB objects over a network to a client that does not have access to the Torque run-time. At present I have to fiddle around with BeanInfo classes to prevent unwanted fields being transmitted, and code extra classes by hand. (RM)

• Provide extra methods that clear down or invalidate all the supplementary fields such as the 'collXXX' arising from foreign keys. (RM)

• Generate struts pages. the idea would be to create a jsp pages form with all the fields by pages, the struts-config.xml, the validator-rules.xml and the {table}Form.java and {table}Action.java. this looks like Xdoclet but this could be great

Maven Plugin

• Generalize into a "code generator" plugin? (hps)

Other

• The code is pretty divergent at this point but maybe integrate Tailrank's Torque fork which includes database sharding. More of this code will be available in 2008 and I'll try to make myself more available for merging [KevinBurton]

---

People:

hps = Henning Schmiedehausen tfischer = Thomas Fischer