On 05/06/2007, at 12:06 AM, 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 c
Hasn't QueryUtils gone poof in 3.0?
/dev/mrg
On 6/5/07, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
So where do we put it then? QueryUtils?
Andrus
: 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
> have
> to. :-) I was thinking about something i
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
have
to. :-) I was thinking about something in CayenneDataObject, but
that
doesn't seem quite right, either for the same r
I don't see a reason to dump it into DataObjectUtils since we don't have
to. :-) I was thinking about something in CayenneDataObject, but that
doesn't seem quite right, either for the same reasoning (although might be
more convenient on users).
As to not having a fetch method in a query class,
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
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 even be
converted into a DataObject, doesn't fe
On Jun 4, 2007, at 10:46 AM, Lachlan Deck wrote:
Will the DataObjectUtils.intValueForQuery work with 3 tier also?
It should. You can look at the sources of the current
DataObjectUtils.objectForQuery - the new method is really just an
extension of it.
Andrus
On 04/06/2007, at 5:40 PM, Andrus Adamchik wrote:
It'd be worth adding support for not only count but avg, max, min,
sum operations on keys... like: [EMAIL PROTECTED]
Sure, but my point was that query should not run itself. Hence the
separation between the query and its execution logic.
It'd be worth adding support for not only count but avg, max, min,
sum operations on keys... like: [EMAIL PROTECTED]
Sure, but my point was that query should not run itself. Hence the
separation between the query and its execution logic.
Maybe the class I posted beforehand could be easily
Hi there,
On 04/06/2007, at 5:05 PM, Andrus Adamchik wrote:
We do have utility classes already, like DataObjectUtils (which are
mainly containers for static methods -- aka functions). This
would be
a "real" class (or extension of an existing class), though.
I am with Matt on the point tha
On Jun 2, 2007, at 4:29 AM, Michael Gentry wrote:
Well, it would work without you providing a DataContext by creating a
default DataContext and using it (obviously, only useful if the model
is simple -- hence also needing a version where you provide the
DataContext to use).
I wouldn't even bo
+1 from me
-Ursprüngliche Nachricht-
Von: Michael Gentry [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 1. Juni 2007 17:44
An: user@cayenne.apache.org
Betreff: Re: performing count
Looking at that CountQuery class makes me think we should actually add it to
Cayenne as a utility class
On 02/06/2007, at 11:29 AM, Michael Gentry wrote:
Also, the query would most likely
need to be SQLTemplate-compatible, not an Expression or Query
(although maybe this can be done -- I'll have to explore). Keep in
mind this is going outside of the ORM arena to a degree. A row count
isn't being
Well, it would work without you providing a DataContext by creating a
default DataContext and using it (obviously, only useful if the model
is simple -- hence also needing a version where you provide the
DataContext to use).
We do have utility classes already, like DataObjectUtils (which are
main
Here's some random feedback ..
I have the need for row counting here and there, so having support in cayenne
would be great.
Couple things ..
>int rowCount = new CountQuery(Artist.class).getCount();
I don't see how this works without a DC - ?
(Maybe I'm just missing something obvious ..)
And
Looking at that CountQuery class makes me think we should actually add it to
Cayenne as a utility class. Perhaps with two additional methods added:
public int getCount();
public int getCount(DataContext dc);
That way you could then do:
CountQuery query = new CountQuery(Artist.class);
int rowC
thx, that is what i've been looking for!
-Ursprüngliche Nachricht-
Von: Michael Gentry [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 1. Juni 2007 16:17
An: user@cayenne.apache.org
Betreff: Re: performing count
The way you show is definitely the wrong approach, as it'll read
The way you show is definitely the wrong approach, as it'll read the entire
table. Try:
http://cwiki.apache.org/confluence/display/CAYDOC/Customizing+Queries
Look at the "Indirect Queries" section at the bottom. That approach would
be much faster.
/dev/mrg
On 6/1/07, Peter Schröder <[EMAIL
It will always be faster for the database to return count(*) than to
fetch all records and count them yourself.
However, if you're going to load those objects into memory anyway, it
may be faster for your application in the long run to fetch them all
up front.
On 6/1/07, Peter Schröder <[EMAIL
hi,
i am wondering about the perfomance-impact of using cayenne to performing an
result-count.
currently i am doing something like this, wich is very straight-forward.
SelectQuery query = new SelectQuery(Tcomrecherche.class,
qualifier);
List list = context.perfo
21 matches
Mail list logo
