Return-Path: Delivered-To: apmail-cayenne-user-archive@www.apache.org Received: (qmail 91916 invoked from network); 5 Jun 2007 13:45:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Jun 2007 13:45:33 -0000 Received: (qmail 36272 invoked by uid 500); 5 Jun 2007 13:45:37 -0000 Delivered-To: apmail-cayenne-user-archive@cayenne.apache.org Received: (qmail 36249 invoked by uid 500); 5 Jun 2007 13:45:37 -0000 Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cayenne.apache.org Delivered-To: mailing list user@cayenne.apache.org Received: (qmail 36240 invoked by uid 99); 5 Jun 2007 13:45:37 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jun 2007 06:45:36 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [194.97.50.131] (HELO mout0.freenet.de) (194.97.50.131) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jun 2007 06:45:31 -0700 Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.68) (envelope-from ) id 1HvZLR-0000EN-5k for user@cayenne.apache.org; Tue, 05 Jun 2007 15:45:09 +0200 Received: from fnhh-svmexfe002.freenet-ag.de ([194.97.108.43]:58178) by mx1.freenet.de with esmtp (port 25) (Exim 4.68 #1) id 1HvZLR-0003ZT-2E for user@cayenne.apache.org; Tue, 05 Jun 2007 15:45:09 +0200 Received: from FNHH-SVMEXDB002.Freenet-AG.de ([195.4.20.141]) by FNHH-SVMEXFE002.Freenet-AG.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 15:45:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: performing count Date: Tue, 5 Jun 2007 15:45:33 +0200 Message-ID: <49D23F7404DC5B4086D7352312597E0F01115D4A@FNHH-SVMEXDB002.Freenet-AG.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: performing count Thread-Index: Acend2UZaDJM4EyUSbmspERiZqrUugAACPEA From: =?iso-8859-1?Q?Peter_Schr=F6der?= To: X-OriginalArrivalTime: 05 Jun 2007 13:45:34.0165 (UTC) FILETIME=[CA610050:01C7A777] X-Virus-Checked: Checked by ClamAV on apache.org first of all: thank u very much for the fast support where do we put it? as a user of cayenne, i dont really care. as long as = it is well documented! kind regards peter -----Urspr=FCngliche Nachricht----- Von: Andrus Adamchik [mailto:andrus@objectstyle.org]=20 Gesendet: Dienstag, 5. Juni 2007 15:42 An: user@cayenne.apache.org Betreff: Re: performing count So where do we put it then? QueryUtils? Andrus On Jun 5, 2007, at 4:31 PM, Michael Gentry wrote: > I don't see a reason to dump it into DataObjectUtils since we don't =20 > have > to. :-) I was thinking about something in CayenneDataObject, but =20 > that > doesn't seem quite right, either for the same reasoning (although =20 > might be > more convenient on users). > > As to not having a fetch method in a query class, I'm fine with =20 > that. I was > asking for opinions, after all. > > Thanks, > > /dev/mrg > > > On 6/4/07, Andrus Adamchik wrote: >> >> >> On Jun 4, 2007, at 5:06 PM, Michael Gentry wrote: >> >> > Putting it in DataObjectUtils doesn't seem the right place to me. >> > Using your example: >> > >> > DataObjectUtils.objectForQuery(...) >> > >> > returns a DataObject (which makes sense to me, being packaged in >> > DataObjectUtils). Something that returns an int, which can't =20 >> even be >> > converted into a DataObject, doesn't feel like it should be in >> > DataObjectUtils. >> >> >> I agree that DataObjectUtils becoming a kitchen sink is bad, and >> "DataObjectUtils" name is a bit obsolete anyways, considering that >> "Persistent" is the interface Cayenne stack is dealing with. So >> DataObjectUtils class itself needs some redesign (split QueryUtils >> out of it or something?) >> >> My other point about not adding fetch methods to the query classes is >> still valid though. So we can either push for DataObjectUtils >> redesign now, or use it as a kitchen sink one more time :-) >> >> Andrus >>