Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
In-Reply-To: 
 <F4DFE8EDB932F641A9407CFB5CA599C301612BB4@e2kmtl1.internal.sungard.corp>
Subject: CountHelper License
To: <Martin.Goulet@sungard.com>
Cc: <torque-dev@db.apache.org>
Message-ID: 
 <OF781D93F7.67F1F364-ONC1256F79.0068CB86-C1256F79.006906CB@seitenbau.net>
From: Thomas Fischer <Fischer@seitenbau.net>
Date: Wed, 29 Dec 2004 20:07:09 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII


Martin,

is it ok for you to put your CountHelper under the apache 2.0 license ?
(http://www.apache.de/licenses/LICENSE-2.0.html)

   Thomas

<Martin.Goulet@sungard.com> schrieb am 21.12.2004 17:29:37:

> Sorry, issue number is TRQS265 (not 165).
>
> MG
> --
> Martin Goulet, B.Sc.
> Senior Software Architect
> SunGard Front Office Solutions
>
>
> -----Original Message-----
> From: Goulet, Martin
> Sent: Tuesday, December 21, 2004 11:28 AM
> To: 'Apache Torque Developers List'
> Subject: RE: Re: [SOURCE] Issue #TRQS256 had user association modified
>
>
> 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
>


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