From torque-dev-return-5274-apmail-db-torque-dev-archive=db.apache.org@db.apache.org Tue May 03 12:25:00 2005
Return-Path:
Delivered-To: apmail-db-torque-dev-archive@www.apache.org
Received: (qmail 94714 invoked from network); 3 May 2005 12:25:00 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur.apache.org with SMTP; 3 May 2005 12:25:00 -0000
Received: (qmail 13979 invoked by uid 500); 3 May 2005 12:19:49 -0000
Delivered-To: apmail-db-torque-dev-archive@db.apache.org
Received: (qmail 13939 invoked by uid 500); 3 May 2005 12:19:49 -0000
Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe:
List-Subscribe:
List-Help:
List-Post:
List-Id: "Apache Torque Developers List"
Reply-To: "Apache Torque Developers List"
Delivered-To: mailing list torque-dev@db.apache.org
Received: (qmail 13897 invoked by uid 99); 3 May 2005 12:19:48 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from mail.seitenbau.net (HELO mail.seitenbau.net) (194.175.229.106)
by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 03 May 2005 05:19:48 -0700
Received: from [195.127.188.18] (helo=www.seitenbau.net)
by router1.seitenbau.net with esmtp (Exim 4.43)
id 1DSwLY-0002Y9-TG
for torque-dev@db.apache.org; Tue, 03 May 2005 14:17:52 +0200
In-Reply-To: <4275F314.1040105@apache.org>
Subject: Re: Torque and Village
To: "Apache Torque Developers List"
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
Message-ID:
From: Thomas Fischer
Date: Tue, 3 May 2005 14:17:53 +0200
X-MIMETrack: Serialize by Router on www/seitenbau(Release 6.5.1|January 21, 2004) at
03.05.2005 02:17:52 PM
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N
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 remova=
l
of) village, if someone else has a better solution, I'll be happy to ac=
cept
it.
In my personal there already exists an interface which satisfies almoas=
t
all needs of Torque - the jdbc interface. I'll try to explain that a bi=
t:
For processing selects, village uses an object called Value, which can =
do
conversions between java types and sql types. The functionality most us=
ed
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, i=
t
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 Torq=
ue,
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. Thi=
s is
not as easy at it seems, as some parts of Torque rely heavily on the va=
lue
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 writt=
en
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 wil=
l 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 interfa=
ce.
If someone has another suggestion for an interface, I'll be glad to hea=
r
it. I will support any sensible way to deal with the village problems.
Thomas
Martin Kal=E9n 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 n=
eed
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 happe=
ns
> > next.. [long time effort... Torque's own dblayer... only if necessa=
ry].
>
> That's IMHO a perfect approach since:
>
> *) work can start immediately
>
> *) it will be crystal clear exactly how Torque is dependent on Villag=
e
>
> *) no more "get the patched Village here"; as you say, the patches
> can be maintained in the Torque adapter layer
> (Torque+Village=3Donly 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 witho=
ut
> > 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 Tor=
que
> > by Village.
> > Torque and DdlUtils can concentrate efforts also in other "use case=
s"
> > probably without having to add an Adapter...
>
> Agree fully. There is nothing wrong with having both a pluggable DB l=
ayer
> 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