I also think that it is a good idea to create an interface, the reasons for
it have already been summarized by Fabio and Martin.
The following is my personal opinion about how to deal with (the removal
of) village, if someone else has a better solution, I'll be happy to accept
it.
In my personal there already exists an interface which satisfies almoast
all needs of Torque - the jdbc interface. I'll try to explain that a bit:
For processing selects, village uses an object called Value, which can do
conversions between java types and sql types. The functionality most used
in Torque is that a Value can hold any sql type that might come along, and
the user can convert it to the appropriate java type later. For this, it
needs to be supplied with the sql type, whis is obtained by village by
querying the sql metadata of a select statement.
This behaviour might be useful for other db layers, but in case of Torque,
the Torque runtime already knows which java type is needed, there is no
need to query the metadata. Instead it causes problems, see e.g.
http://issues.apache.org/scarab/issues/id/TRQS285.
To me, the most satisfactory solution would be to dispose of the Value
object altogether, and work with jdbc ResultSets on the query side. This is
not as easy at it seems, as some parts of Torque rely heavily on the value
concept (for example the IdGenerator interface)
For performing inserts/updates, village has got two functions :
1) create the sql for a prepared statement for the insert/update
2) fill the prepared statement with the appropriate values
We would need to define an interface for 1) Then e.g. ddlutils could be
used for that. The interface for 2) could be the jdbc PreparedStatement.
Maybe some wrapper around the PreparedStatement interface must be written
in order to deal with the LOB issues in oracle.
But this kind of solution is certainly not compatible with the village api.
So the idea of a gradual refactoring seems intriguing at first, but will be
lost work if the final solutions should be something as I have sketched
above.
Again, this is just my personal opinion, but it seems to me that some
careful thinking is needed before one rushes off and creates an interface.
If someone has another suggestion for an interface, I'll be glad to hear
it. I will support any sensible way to deal with the village problems.
Thomas
Martin KalÚn schrieb am 02.05.2005 11:29:56:
> Fabio Insaccanebbia wrote:
> > suggestion: what about a "pluggable" dblayer for Torques?
>
> +1 I think this idea is brilliant!
>
> > We could design the API that Torque needs, create a Village Adapter
(for
> > compatibility with the past) a DdlUtils based db layer and, if we need
a
> > "custom - made" dblayer, we can write our own (or we can find a
> > new/better in the Open Source space).
> >
> > So we can start with Village (putting our patches in the "Adapter"
layer
> > if we really want to) [short time effort], then start an effort to
write
> > the DdlUtils based db layer [medium time effort] and see what happens
> > next.. [long time effort... Torque's own dblayer... only if necessary].
>
> That's IMHO a perfect approach since:
>
> *) work can start immediately
>
> *) it will be crystal clear exactly how Torque is dependent on Village
>
> *) no more "get the patched Village here"; as you say, the patches
> can be maintained in the Torque adapter layer
> (Torque+Village=only 2 code repositories instead of current 3)
>
> *) making this work for Village in the existing code will prepare for
> DdlUtils "plug-in" later
>
> > Obviously the difficult thing would be to create an API that makes
> > simple to create adapters both for Village and DdlUtils (thus without
> > complex hierarchy, with the minimum API objects number).
>
> Since this API is 100% internal there will be lots of room for
refactoring
> later. Starting with Village will be a good first try, trying to plug in
> DdlUtils later -- with some additional API refactorings if needed -- will
> make the DB layer API even better (as will be the case for each new
> added product).
>
> > P.S.: I'm just talking about the functions currently covered in Torque
> > by Village.
> > Torque and DdlUtils can concentrate efforts also in other "use cases"
> > probably without having to add an Adapter...
>
> Agree fully. There is nothing wrong with having both a pluggable DB layer
> adapter for DdlUtils and some other direct compile-time depdencies on
> different areas of the same package.
>
> If you guys decide that this is the way to go, I would be happy to
> help you with any code I can contribute with!
>
> Regards,
> Martin
>
> ---------------------------------------------------------------------
> 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