You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by Thomas Fischer <tf...@apache.org> on 2006/12/02 11:29:16 UTC
Status of discussion Torque 4.0
Hi,
To get an overview of the torque 4.0 discussion status, here's what I
consider the current status of discussion. If you think otherwise, please
complain. I'll also set up a wiki page which is intended to keep pace with
the current state of discussion (but not as replacement for discussion on
the dev list, so I'll ask folks to discuss features on the dev list before
they are added to the wiki)
Consensus on the following points:
- Next main version should be 4.0.
- Simplify the repository structure: No svn externals any more
- Kick out village
- Change the way to handle non-record-type queries (we used village for
that until now)
- Criterias should not be modified any more inside queries.
- Disentangle Query description and SQL creation code.
- Use the Criteria object only to hold query data and another object to
hold update data. Criteria should not extend Hashtable any more.
- Use a column object to hold the column name in the runtime instead of
Strings
- Support views
- Use a custom velocity renderer to have nicely trimmed generated code.
- Have a non-static version of Peer classes. Implementation details are
under discussion.
- Evaluate whether ddlutils can be used for some generator tasks
Under discussion:
- Switch to Maven 2 as build system.
- Make the generator more generic.
- Support primitives in data objects
Problematic:
- Use Java 5 style generics and enumerations. Java 5 code does not run on
jdk 1.4
Torque 4.5:
- Support for object level views
Torque 4.5, Under discussion
- Support for lazy loading
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Status of discussion Torque 4.0
Posted by Thomas Fischer <tf...@apache.org>.
+1 on both of that. You want to add that to the wiki ?
On Fri, 8 Dec 2006, Thomas Vandahl wrote:
> Thomas Fischer wrote:
>> Consensus on the following points:
> [...]
>
> I'd like to add a few things that we discussed privately.
>
> I'm planning to extend the caching capabilities of Torque so that a
> transparent caching layer can be used if needed. This just needs some
> completion of features already there. Caching normally is easy, correct
> invalidating of cache entries is not. Most of the invalidation
> requirements can be derived from the complexObjectModel, however (I hope).
>
> If we drop some of the statics in Torque, integration in several
> component services should be easier. I'd like to add a few features here
> to make Torque play nicely with other components and containers.
>
> Bye, Thomas.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Status of discussion Torque 4.0
Posted by Thomas Vandahl <tv...@apache.org>.
Thomas Fischer wrote:
> Consensus on the following points:
[...]
I'd like to add a few things that we discussed privately.
I'm planning to extend the caching capabilities of Torque so that a
transparent caching layer can be used if needed. This just needs some
completion of features already there. Caching normally is easy, correct
invalidating of cache entries is not. Most of the invalidation
requirements can be derived from the complexObjectModel, however (I hope).
If we drop some of the statics in Torque, integration in several
component services should be easier. I'd like to add a few features here
to make Torque play nicely with other components and containers.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Java5 (was: Torque 4.0 plan)
Posted by Thoralf Rickert <th...@cadooz.de>.
I don't have an idea of "how can we support JDK1.5 and JDK1.4" because of the compatibility problems between 1.4 and 1.5 - but I think like Thomas that we have to make a break. The next release of the JDK is on the way and we're still programing in the "old" 1.4. I don't want to start a principle discussion - I know that many developers cannot easily switch to a new JDK.
Currently we have the best solution for 1.4 and 1.5. If you change a switch and rerun the generator you have JDK1.5 compatible generated classes. Maybe there are some places in the templates that could be more Java5 compatible (foreach, generics, enums). But this would change the API very much and the underlying Torque-API uses still "just" JDK1.4. A new major release could be a good moment to think about this API changes. Removing Village means in any case that existing projects have to be reviewed before switching to Torque 4.0.
The only disadvantage I can think about is, that projects that cannot switch to JDK1.5 don't have access to the new features that we plan to implement and we have to backport bugfixes to the 3.x tree if we find some in Torque. Because we cannot say "Switch to Torque 4.0 if you have a problem".
What about the Tomcat solution. They have a 5.0 tree for <Java5 system and a 5.5 tree for >=Java5 system. I don't know how they manage this, because this means they have two branches. Does somebody know how they do this?
Thoralf
________________________________
From: Thomas Fischer
[...]
>Problematic:
>
>- Use Java 5 style generics and enumerations. Java 5 code does not run on
> jdk 1.4
[...]
>>You are right, I was not aware of this. So what do we do ? I'd guess most
>>people will use java 1.5 by the time the new release is ready (I do not
>>think less than a year's development time is realistic), but I'm also sure
>>there are some users who cannot use Java 1.5.
>>Supporting 1.5 in the generator is the minimum option (we have that
>>already), but my original idea was to port the runtime and the other stuff
>>as well.
>>I'd guess if we do not do it in the step towards 4.0 we'll never make that
>>transition.
>>I'm undecided. Any opinions ?
>> Thomas
[...]
________________________________
From: Jonathan Purvis....
>>>> - Use Java 5 style generics and enumerations. One can use compiler
>>>> settings to produce pre-1.5-executable class files.
>>>The autoboxing in 1.5 of int to Integer uses Integer.valueOf(int),
>>>which doesn't exist in 1.4. Also, javac won't let you:
>>> $ javac -target 1.4 Generic.java
>>> javac: target release 1.4 conflicts with default source release 1.5
>>> $ javac -target 1.4 -source 1.5 Generic.java
>>> javac: source release 1.5 requires target release 1.5
>>>Could it be an option on the generator instead?