db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Martin.Gou...@sungard.com>
Subject RE: Re: [SOURCE] Issue #TRQS256 had user association modified
Date Tue, 21 Dec 2004 16:27:36 GMT
Henning and Thomas,

I've created issue TRQS165 in Scarab for the new version of the patch.
It includes
all the changes that both of you recommended.

Thomas,

I understand that you can make the change to use buildQuery() instead of
BasePeer.doSelect().
This is most appreciated. :)

>> > You should be able to get the deliminator from buildQuery()?
>>
>> > Why use the doSelect() anyway? Why not use the primitives to build
the
>> > SQL string and send it to the DB?
>>
>> Why not?
>
>Well, here I agree with Henning again. He has done a lot of effort to
>centralize SQL generation in one place, because only then you  can
>guarantee standard behaviour for each call. But I can also change this,
>because there are a lot of recent changes in CVS (current active Branch
ist
>TORQUE_3_1_BRANCH, the methods to build the SQL from Criteria are in
>SQLBuilder), so do not bother about this.

Thx!

MG 
-- 
Martin Goulet, B.Sc. 
Senior Software Architect
SunGard Front Office Solutions 


-----Original Message-----
From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
Sent: Monday, December 13, 2004 1:58 PM
To: torque-dev@db.apache.org
Subject: Re: [SOURCE] Issue #TRQS256 had user association modified


<Martin.Goulet@sungard.com> writes:

>Henning: Thx for the feedback! (even though bedside manners doesn't
seem
>to be your strong point...

I'm quite busy ATM and write short comments that might sound harsh. I
know, this is not intended to be harsh, just to the point. If you felt
offended, I apologize.

However, this is a development list and code critisism is intended to
improve the code quality, not to put people down.

>remember I just want to contribute a bit back to the community with a
>feature that I think is 
>useful)

We all are grateful for contributions. But that does not mean, that
every patch gets applied without discussion. IMHO there is no reason
to add another number of convenience methods to an already bloated
class. These methods can well be inside a helper class (CountHelper
e.g.)

>> Uh, do we really want to bloat up the Peer classes any further? What
>> sense in putting this into BasePeer?

>Ok, where would you put it?

o.a.t.utils.CountHelper e.g. 

[...]

>> Why are you doing all the shebang in count(Criteria, Connection,
>> columnName, distinct) ?  Am I missing something?

>In order to issue the 'count' call the criteria is modified. So in
order
>to restitute it in the original form, we are resetting the columns and 
>the 'order by columns' in the original states. With this, the called
>doesn't
>need to keep a copy of his original object.

Is there a need to keep state? AFAIK none of the other methods keep
the state of the Criteria. IMHO, just run the count and be done with
it. Put a notice on top of the Methods that the state of Criteria is
destroyed.

>> You should be able to get the deliminator from buildQuery()? 

>> Why use the doSelect() anyway? Why not use the primitives to build
the
>> SQL string and send it to the DB?

>Why not?

Because doSelect() is expensive as hell. It runs through all the
Village hoops just to return (in the end) a single integer value. I'd
expect to run a simple Criteria parser + straight SQL to run 10-20
times faster. However, this probably won't be visible compared to the
DB time for the select anyway. :-)

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for
hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

What is more important to you...
   [ ] Product Security
or [ ] Quality of Sales and Marketing Support
              -- actual question from a Microsoft customer survey

---------------------------------------------------------------------
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