Differences between revisions 11 and 12
Revision 11 as of 2009-09-20 23:04:22
Size: 4507
Editor: localhost
Comment: converted to 1.6 markup
Revision 12 as of 2013-05-25 20:06:12
Size: 2176
Comment: Remove already implemented stuff
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
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
Don't expect everything written here to show up at once.
Line 13: Line 12:
 * Get rid of the static Peer classes. (hps)

 * Get rid of Village. (hps,tfischer)
Line 18: Line 13:

 * Defined datatypes for SQL columns and tables. (hps,tfischer)
Line 23: Line 16:
 * Move functionality from the generated Peer and Object classes back into the runtime. (hps)
Line 26: Line 17:

 * (Maybe) split up the Criteria into an Insert / Select / Delete criteria (hps,tfischer)
Line 35: Line 24:
 * Improve handling of 1:n relations: Add support for deleting related objects (tfischer)
Line 38: Line 25:

 * 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)
Line 47: Line 30:
 * 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)
Line 53: Line 34:
 * 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)
Line 59: Line 36:
 *  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 [[http://spinn3r.com/opensource.php#torque|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]
 * 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

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.

General

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

Torque Runtime

  • General SQL schema (database namespace) support. (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)
  • 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)
  • 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)
  • (Maybe) handle n:m relations automatically ? (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

  • 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)
  • 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


People:

hps = Henning Schmiedehausen tfischer = Thomas Fischer

TorqueFuture (last edited 2013-05-25 20:06:12 by ThomasFischer)