Re: How can I cast a NSMutableDictionary to a EOEnterpriseObject

On Nov 19, 2008, at 5:03 PM, Mike Schrag wrote:

>>>> Exactly.  Out of curiosity, how often do you do raw row fetches  
>>>> of all of the attributes?  Most of the time, I am only fetching a  
>>>> small sub-set.  That usage pattern may have been the original  
>>>> intention and why no attempt was made to populate the snapshot  
>>>> cache.  That said, this does seem like a very useful optimization.
>>> I'm most interested in this optimization for being able to do  
>>> highly optimized joins that I can then turn around and fill  
>>> multiple snapshot cache entries at once.  For instance if I have a  
>>> mandatory to-one relationship that I want to prefetch, if EOF was  
>>> smart they would do that in a single query and fill in the  
>>> snapshot cache for both EO's at once, but it's not that smart,  
>>> it's really stupid and it does two queries.  If I have an optional  
>>> prefetched to-one, it should do an outer join for me and do that  
>>> in one query, but it does two queries ... There are also times  
>>> when I need to do much more complicated SQL queries and I end up  
>>> joining other tables to do it, so I end up with entity columns +  
>>> other stuff that I can ignore that I would like to be able to do  
>>> this.  So anyway, it's entirely a performance optimization for  
>>> complicated scenarios, but it would be nice to have the option to  
>>> do it relatively easily ...
>> Confused...  This does not sound like the "create an EO from a raw  
>> row" that I thought we were discussing.  What you are describing  
>> sounds to me like EOF's lame inability to fetch more than one  
>> entity with a single select.  That is definitely a performance  
>> problem, but I think the solution is more involved than getting  
>> objectFromRawRow to use the data it is passed instead of faulting.
> I agree it's a little different than the original problem  
> description, but it's only by a little bit.  The root problem is  
> basically the same, I was just originally shielding the discussion  
> from my full evil desires :) There are some issues that need to be  
> resolved with fully qualified column names coming out for  
> disambiguation, but all of this is totally solvable.

Yes.  But I don't think you can do it.  :-P


> Although, I'm actually a little curious about the performance  
> difference between fetching raw rows vs full EO conversion, that  
> might be beneficial performance-wise to do batch fetching with raw  
> rows and only promote to an EO when you actually need it ... I've  
> never benchmarked it, but I've always wondered.


The difference between a raw row fetch and an EO fetch is significant,  
but not on the scale of a raw SQL fetch (e.g. in a database tool) to a  
raw row fetch.  I think.  I tested this once, a while ago.  The EO  
creation cost was not as high as I had assumed it would be.  But if  
you can fetch lots of raw rows and only convert some of them into EOs,  
that is a real performance gain in a highly optimized setting.

Chuck

-- 
Chuck Hill             Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their  
overall knowledge of WebObjects or who are trying to solve specific  
problems.
http://www.global-village.net/products/practical_webobjects