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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
