Mailing-List: contact torque-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Users List" <torque-user@db.apache.org>
Received-SPF: pass (athena.apache.org: domain of greg.monroe@dukece.com
 designates 152.3.166.24 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: Village meta data calls (Was: Will migrating from 3.0 to 3.3 help
 me?)
Date: Thu, 2 Oct 2008 11:54:38 -0400
Message-ID: <8F5843B903F59D4C8C6806BB49A39119082D7C4F@dukece-mail3.dukece.com>
In-Reply-To: <48E4C54D.3040504@backstagetech.com.au>
Thread-Topic: Village meta data calls (Was: Will migrating from 3.0 to 3.3
 help me?)
Thread-Index: Ackkjqka8fvqk2EvSGamxTp3+cC+rwAExMeg
References: <c6753c3a0809292015r5d474be0l3677446aaf4c15ab@mail.gmail.com>
 <48E3091E.3050502@backstagetech.com.au>
 <48E4C54D.3040504@backstagetech.com.au>
From: "Greg Monroe" <Greg.Monroe@DukeCE.com>
To: "Apache Torque Users List" <torque-user@db.apache.org>
Content-Type: text/plain;
	charset="us-ascii"

I'm in agreement that we need to fix this=2E=2E=2E but on the other hand, =
=0D=0Ait's been part of Torque since day one and the performance hit hasn't=
=0D=0Amotivated anyone into fixing yet=2E=2E=2E 8)=2E=0D=0A=0D=0AA couple o=
f things to note about the meta data calls (from the memory =0D=0Aof wading=
 thru the Village code in that past and may not be fully =0D=0Aaccurate=2E=
=2E=2E)=2E  =0D=0A=0D=0AFirst, although Torque may not use the Column objec=
t directly, the =0D=0AVillage internals for doing updates and inserts use i=
t a lot=2E  Torque =0D=0Acurrently uses Village calls to do these actions=
=2E=0D=0A=0D=0ASecond, we may not want/be able to eliminate all calls to th=
e meta-data=2E=0D=0AIf my memory is correct, Village checks the meta data i=
n order to =0D=0Aproperly convert the supplied value into the format the da=
tabase =0D=0Aexpects=2E  =0D=0A=0D=0AIMHO, I think this has been secretly h=
elpful in automatically mapping=0D=0Abetween Torque's XML schema and the na=
tive columns=2E  Especially when=0D=0Athe tables have not been created via =
Torque=2E  It means you just have =0D=0Ato find a data type that's "close" =
to the native one and then Village=0D=0Aand JDBC maps it correctly to and f=
rom Torque objects=2E=0D=0A=0D=0AIf we don't want to lose this functionalit=
y, we still need to do some=0D=0Achecking as to what the underlying column =
type is=2E  I'm thinking that=0D=0Athis information should get added to the=
 ColumnMap object and the =0D=0Ainitialization routines changed to make the=
 call to get the Meta=0D=0Adata=2E  This would cache the meta data, cut the=
 meta data requests to=0D=0Ajust a few, and still maintain the underlying V=
illage flexibility=2E=0D=0A=0D=0AJust some quick thoughts on this=2E  Take =
them or leave them=2E=0D=0A=0D=0AGreg=0D=0A=0D=0A> -----Original Message---=
--=0D=0A> From: Scott Eade [mailto:seade@backstagetech=2Ecom=2Eau]=0D=0A> =
=0D=0A> I am not telling you anything you don't already know, but it sure i=
s=0D=0A> interesting to see this myself=2E=0D=0A> =0D=0A> Looking at torque=
, the only references to=0D=0A> com=2Eworkingdogs=2Evillage=2EColumn=0D=0A>=
 (directly and via c=2Ew=2Ev=2ESchema) are in=0D=0Aorg=2Eapache=2Etorque=2E=
util=2EBasePeer=2E=0D=0A> Usage would appear to be limited to retrieving th=
e name of the column=0D=0A> (via Column) and the number of columns (via Sch=
ema)=2E=0D=0A> =0D=0A> So it looks to me like we should look at producing a=
 version of=0D=0AVillage=0D=0A> that skips retrieving unnecessary metadata=
=2E  For people using JDBC=0D=0A> drivers that implement the metadata retri=
eval methods this will result=0D=0A> in a performance improvement significa=
ntly larger than any other=0D=0A> refactoring we might be considering for 4=
=2E0 and potentially this could=0D=0A> be substituted into to a 3=2E3=2E1 r=
elease with just an updated pom=2E=0D=0A> =0D=0A> I have a couple of dozen =
other things on my plate right now, but if=0D=0A> someone else cares enough=
 to verify my analysis I don't think it will=0D=0A> be=0D=0A> too difficult=
 to achieve something positive out of this=2E=0D=0A> =0D=0A> Scott=0D=0A> =
=0D=0ADukeCE Privacy Statement:=0D=0APlease be advised that this e-mail and=
 any files transmitted with=0Ait are confidential communication or may othe=
rwise be privileged or=0Aconfidential and are intended solely for the indiv=
idual or entity=0Ato whom they are addressed=2E If you are not the intended=
 recipient=0Ayou may not rely on the contents of this email or any attachme=
nts,=0Aand we ask that you please not read, copy or retransmit this=0Acommu=
nication, but reply to the sender and destroy the email, its=0Acontents, an=
d all copies thereof immediately=2E Any unauthorized=0Adissemination, distr=
ibution or copying of this communication is=0Astrictly prohibited=2E

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org