This is part support, part ticket, and part suggestion. But it appears that $record->exists() inside a post::commit() callback is FALSE. It kinda feels like I just commited the data... so at that point shouldn't the record exist?
The behavior you are seeing is intended. It is very often necessary to be able to detect that a record was just added to the database after the commit operation. If fActiveRecord::exists() returned
TRUE in this situation, there would be no way to know when you've just inserted a record into the database for the first time.
From an implementation perspective, fActiveRecord::exists() basically just returns
TRUE when there are no
$old_values entries for the primary key of the record, but there are primary key entries in the
$values array. It is actually the very last step of fActiveRecord::store() to reset the
$old_values array to a clean state, which causes fActiveRecord::exists() to now return
I use this functionality pretty extensively in plugins and in my own code, so I would be hesitant to change it. Perhaps there could be a better way to handle this situation? I'd be open to discussing changing how this situation is detected, but it is definitely functionality that would need to remain available.
If this is the case, perhaps another callback could be added, of what name I do not know. The confusion for me here was that it was 'post::store()' -- 'post-commit::store()' I think is another one, which I possibly wouldn't presume it to be true for... but I feel 'post::store()' should be almost equivalent to running something right after the ->store() call. Obviously the benefit of a hook callback is that if you store the record in multiple places you can just add the callback rather than repeating whatever the code is after that needs to be done.
I don't know if there is a clean way to "fix" it without breaking backwards compatibility, but at the very least I feel it should be clearly documented somewhere that the exists() method will return FALSE during all ORMCallbacks and does not return true until store() returns. The code which raised this issue is fixed otherwise, so it's not some huge deal... it was just sorta confusing and/or non-intuitive.