Dear Wiki user, You have subscribed to a wiki page or wiki category on "Db-torque Wiki" for change notification.
The "TorqueFuture" page has been changed by ThomasFischer: https://wiki.apache.org/db-torque/TorqueFuture?action=diff&rev1=11&rev2=12 Comment: Remove already implemented stuff = 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. - 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 == @@ -12, +11 @@ == 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) @@ -34, +23 @@ * 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 + * 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] ---- People: --------------------------------------------------------------------- To unsubscribe, e-mail: torque-dev-unsubscr...@db.apache.org For additional commands, e-mail: torque-dev-h...@db.apache.org
