Probably found the culprit.
I have added the appropriate attribute programmatically to the entity; and it seems that it was NOT added -- and therefore storedValueForKey did not find it. Makes sense. Oh, sigh.
Hello there,
I must be missing something very obvious now.
My application (rather complex) lately started sometimes to go stack overflow. I have found the culprit is a code where I call storedValueForKey in my own ERXGenericRecord subclass. The stack goes like this:
(i) handleQueryWithUnboundKey (which my EO overrides) get called -- I do some internal checking there, and eventually call my own installed accessor, essentially, 'this.foo()'. That works well.
(ii) the 'foo' accessor contains just "this.storedValueForKey('foo')", and it indeed gets called all right.
(iii) now, I thought it would try to get the value of 'foo' from snapshot, or fetch it from the database, or whatever. I was wrong -- it goes again to handleQueryWithUnboundKey, GOTO (i), stack overflow.
Here's the important part of backtrack:
===
...
at cz.ocs.model.OCSEnterpriseObject.handleQueryWithUnboundKey(OCSEnterpriseObject.groovy:1173)
at com.webobjects.foundation.NSKeyValueCoding$Utility.handleQueryWithUnboundKey(NSKeyValueCoding.java:494)
at com.webobjects.foundation.NSKeyValueCoding$_KeyBinding.valueInObject(NSKeyValueCoding.java:894)
at com.webobjects.eocontrol.EOCustomObject.storedValueForKey(EOCustomObject.java:1634)
at com.webobjects.eocontrol.EOKeyValueCoding$storedValueForKey.call(Unknown Source)
at cz.ocs.model.OCSEOUtilities$FOO_ACCESSOR(OCSEOUtilities.groovy:60)
...
at cz.ocs.model.OCSEnterpriseObject.handleQueryWithUnboundKey(OCSEnterpriseObject.groovy:1173)
...
===
It even is documented thus, EOCustomObject.storedValueForKey tries first _foo and foo, then... yadda yadda ... and if all fails, it is documented to go handleTakeValueForUnboundKey (which seems to be a typo in documentation, meaning handleQueryWithUnboundKey
instead):
===
...
public Object storedValueForKey(String key)
Returns the value for the property identified by key. This method is used when the value is retrieved for storage in an object store (generally, this is ultimately in a database) or for inclusion in a snapshot. The default implementation provided by EOCustomObject
is similar to the implementation of valueForKey, but it resolveskey with a different method instance variable search order:
• Searches for a private accessor method based on key (a method preceded by an underbar). For example, with a key of "lastName", storedValueForKey
looks for a method named _getLastName or _lastName.
• If a private accessor isn't found, searches for an instance variable based on key and returns its value directly. For example, with
a key of "lastName",storedValueForKey looks for an instance variable named _lastName or lastName.
• If neither a private accessor or an instance variable is found, storedValueForKey searches for a public accessor method based on key.
For the key "lastName", this would be getLastName or lastName.
• If key is unknown, storedValueForKey calls handleTakeValueForUnboundKey.
...
===
But darn, _where_ then is the specific EOF code to get the attribute value from snapshot/from database? So far I thought EOCustomObject overrides the generic storedValueForKey appropriately (so that instead of trying _foo, _getFoo, foo and getFoo it reads
from snapshot/database). It does not seem to, though?!?
What am I missing here?!?
Thanks a lot,
OC
Do not post admin requests to the list. They will be ignored.