Re: How can I cast a NSMutableDictionary to a EOEnterpriseObject

>>> 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.

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.

ms