db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <fisc...@seitenbau.net>
Subject Re: Torque 4.0 plan
Date Thu, 30 Nov 2006 12:39:21 GMT

Ups, I knew I forgot something on the list. This was in my mind but did not
make it into the email.
As you wrote, the problem of static methods is that you cannot override its
behaviour. The beauty of static methods is that invocation is very simple.

The idea would be to have a static Wrapper class, which holds a singleton
of the class with the implementation, and which passes all its static calls
to the implementation class. There would be a setter of the singleton in
the static class, so the backing class would be exchangeable.
So one can use the static class if simple invocation is wanted, and the
implementation class if maximum flexibility is needed.

   Thomas

joe.carter@gmail.com schrieb am 30.11.2006 11:58:25:

> Is there any chance we can make the Peer classes non-static?
> Currently it's hard/impossible to override/extend these without making
> generator changes. Perhaps have some form of central "registry" to
> hold these classes so that they can be globally looked up but
> also replaced/extended if desired.
>
> The other suggestions are all very good - especially removing village.
>
> Thanks
>
> Joe
>
> On 29/11/06, Thomas Fischer <tfischer@apache.org> wrote:
> >
> > 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:
> >
> > - Next version should be 4.0. There can be major changes in the
version,
> > but the 'look and feel' should change as little as possibl. The idea
> > would be that one can recompile one's Torque 3.2 or 3.3 project with
the
> > new Torque version and it should run with minor changes only.
> >
> > - Switch to Maven 2 as build system. Maven 2 has much better
multiproject
> > support than Maven 1, so building will be easier.
> >
> > - Simplify the repository structure: No svn externals any more. This
would
> > mean that all Torque components can only be released simultaneously,
but
> > as we have done so in the past anyway and compatibility problems would
> > arise if we would'nt do so, this should not be problematic.
> >
> > - Use Java 5 style generics and enumerations. One can use compiler
> > settings to produce pre-1.5-executable class files.
> >
> > - Kick out village. Village is bad. See the issue tracker for details.
> > This would mean: create the sql to insert / update objects ourselves;
do
> > the Torque type / SQL type mapping of variables orselves; create
objects
> > directly from jdbc result sets.
> >
> > - Use the Criteria object only to hold query data and another object to
> > hold update data. Criteria should not extend Hashtable any more nor
> > sahould it implement the map interface, cause query data is not a Map
in
> > any sense (e.g. the same column names can appear more than once in a
> > criteria)
> >
> > - Criterias should not be modified any more inside queries. Of one
needs
> > modification, one can copy the criteria.
> >
> > - Disentangle Query description and SQL creation code. In my eyes, it
> > would be ideal to port the MVC paradigm to the SQL creation: The
criteria
> > is the model (what do I want to query), the view would cretae the SQL
from
> > the Query, and the controller would be the Peer class which executes
the
> > query.
> >
> > - Use a column object to hold the column name in the runtime instead of
> > Strings. So one could remove all that distributed guesswork of "what is
> > the table name, do we have a schema name or not" etc. This would also
have
> > the advantge that a String is clearly a value and not a column name.
> >
> > - Make the generator more generic. I'd like to turn the generator into
a
> > generiy code generation tool, which can be used to create all sort of
> > code, not just database access code. I'm currently working on a
proposal.
> >
> >    Any opinions ?
> >
> >       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


Mime
View raw message