Prematurely looking for a fetch solution that does not overkill the database 
when the we don't know if the fetch overkills the database yet.  :-)

Regards Kieran
___________________________
Sent from my iPad.


On Mar 5, 2012, at 9:44 PM, Paul Yu <[email protected]> wrote:

> Premature what?
> 
> -- 
> Paul Yu
> Sent with Sparrow
> 
> On Monday, March 5, 2012 at 8:55 PM, Kieran Kelleher wrote:
> 
>> Donald Knuth once said "premature optimization is the root of all evil" :-)
>> 
>> Try it out before assuming the performance is bad. If your tables have the 
>> needed indexes it should be fine.
>> 
>> If performance is bad, log the generated SQL and just apply whatever tools 
>> you have at your disposal for your database platform to figure out the 
>> problem (index, join buffer size, etc.)
>> 
>> Regards Kieran
>> ___________________________
>> Sent from my iPad.
>> 
>> 
>> On Mar 5, 2012, at 3:43 PM, Jesse Tayler <[email protected]> wrote:
>> 
>>> 
>>> is there a proper way to fetch across a to-many and not overkill the 
>>> database?
>>> 
>>> if I wanted to return a list of recently used venues that the user has 
>>> associated with posts they have authored, I'd want a distinct return of 
>>> venues, each having a post->author being the user, but this query like this 
>>> would just churn on the database wouldn't it?
>>> 
>>> I didn't see a "distinct" wonder fetch property either, don't I have to use 
>>> something to ensure the list is returned without duplicates?
>>> 
>>> EOQualifier qual = Venue.POSTS.dot(Post.AUTHOR_KEY).eq(user());
>>> ERXRestFetchSpecification<Venue> fetchSpec = new 
>>> ERXRestFetchSpecification<Venue>(Venue.ENTITY_NAME, qual, null, 
>>> queryFilter(), Venue.CREATED.descs(), 25);
>>> 
>>> what's the best practice on that kind of fetch?
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/kelleherk%40gmail.com
>>> 
>>> This email sent to [email protected]
>> 
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/pyu%40mac.com
>> 
>> This email sent to [email protected]
> 
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to