[eluser]OverZealous[/eluser]
[quote author="sethbaur" date="1250277101"]Now, in the config I set "auto_populate_has_one" to TRUE. When I do this, whichever is the first "include_related" fails, but the second works.[/quote]
I was looking this over, and I know what's happening. It makes sense now.
Basically, there is only one ActiveRecord object, which means you can only set up and run one query at a time.
However, auto_popupate_* can magically get run at any time. And it automatically loads the related item by using AR. So, the code in your example gets trampled when the auto populate kicks in.
There are several solutions, the first two you can use right now:
1) Don't use auto_populate (at all). Not really a great recommendation, because it can be a great feature for $has_one relationships.
2) Make sure you always access related items before calling include_related:
Code:
$updates = new Update();
$updates->uri; // ensures that it is preloaded
$updates->section; // ensures that it is preloaded
$updates->order_by('created', 'DESC')
->include_related('uri', array('uri_string'))
->include_related('section', array('title'))
->get($per_page);
This is a good, short-term workaround until I get the next release out there with a more permanent fix.
3) I can make changes to DMZ to not use auto_populate when accessed while using a query method. The drawback here is it can leave your object unloaded, and it will then never get autoloaded. It also requires a little work on my part, to ensure that the object never gets autoloaded while setting up a query. And it only would help from within the object's query methods, not if the object is accessed independently.
4) When autoloading an object, deeply clone the DB object, so it has it's own, independent copy of the database object. I have already had to do this for one of my functions. This could be a performance issue, because as of PHP 5.2.10, this is the only way I've found to ensure that the DB object is deeply cloned (and the ActiveRecord arrays are not shared):
It's less than ideal. But it does prevent the related object's query from trampling over the main query.
5) I could "back up" the current object's query when auto loading, and then "restore" it afterwards. And now, the more I think about it, this seems like the correct one to try. It has the lowest performance penalty (only once per auto-load).
I did already add one minor benefit: the auto_load code will no longer run on objects that do not exist(). So, in your example, it would not have run, because it was a new Update.
