[dev] Recent RDO changes

[Chuck Hagenbuch]

Quoting Michael Rubinsky <mike at theupstairsroom.com>:

> Thanks for the feedback, Chuck - I totally understand it's  
> impossible  to prevent breaking code that you don't know about ;)

I should add the other part is that RDO isn't stabilized yet. I  
shouldn't be breaking even code I didn't know about if it was a stable  
API. :)

> I can dump my code in the incubator if you like, although I really  
> wouldn't expect you to tailor any horde changes to my little  
> application's needs  anyway.  Part of the reason I haven't put this  
> in the incubator is  because of the way I've been developing it...in  
> big chunks here and  there and I don't want to litter the commit  
> lists with huge,  non-atomic commits.

That's fine; I certainly don't need it in incubator, but you're  
welcome to put it there if it's something others would be interested  
in. But I do want your ongoing feedback as you use it.

> I agree that on the one hand, the storage drivers should probably be  
>  encapsulated within the mapper, but the flip side of that argument  
> is  that leaving it accessable allows for more flexability with the  
> types  of queries you want to run.  For example, I need to calculate  
> the SUM  of a number of fields in my areos_flights table. I'd much  
> rather have  mySQL do the calculation via a SUM() query rather than  
> getting the  data and totalling it within php.  Unless I'm missing  
> something (which  happens more than I care to admit), I don't see  
> any way to perform  arbitrary queries using just the mapper. Other  
> needs that come to mind  are DISTINCT queries... Any hints on other  
> ways to do this would be  welcome.

The goal with the core mapper api is to make it independent of SQL, so  
that limits what can be put into the mapper api - and I'd like to keep  
that simpler anyway. But it's obvious to me that ORM solutions are not  
going to be optimal for all apps and that we will wind up losing if we  
try to make it automatically be smart enough to do all the correct  
SQL. So allowing individual mapper implementations to use the storage  
backend independently is definitely a good idea.

I think my suggestion to create your own DML object and to use it to  
generate the SQL you want to pass to the backend - or even just  
passing in the right SQL, you don't have to use Query objects if you  
don't get something from it and you're already tied to SQL - is the  
way to go here.

Also, I don't think it'd hurt to make the dml object available as a  
public instance variable, so you could use $ob->dml->foo(). Any  
thoughts?

-chuck

-- 
"we are plastered to the windshield of the bus that is time." - Chris