What happens is that the hydration process detects it already has a Model object in cache for that table and primary key, so it simply links in the cached object instead of hydrating the result and create a new object.
As you have noticed, this has side-effects when you do partial selects.
The reason for this caching is that hydration is a very expensive process, and will make the ORM slow, so you would like to avoid it where possible. Also, it ensures at all code uses the same object, so you can't run in the situation where you call delete() on object A, and have a copy of that same record in object B that doesn't know it was deleted.
For every DB access you need to think whether you should use ORM or DB calls.
The current ORM has quite a few limitations or "quirks", the entire hydration/caching bit being one of them. There is a method from_cache(), which allows you to switch off the cache check, but it doesn't work nicely with relations so it's no fix for your problem.
We're currently redesigning the ORM for Fuel v2, which is the moment to address these issues. The current code is way to complex so implement such architectural changes.
Donate
