Thanks both of you. Very weird: always, far as I can recall, even years ago
when in my hierarchy used to be EOGenericRecord instead of ERX... one, they
were nulls :-O (Of course there is a slight probability my memory plays tricks
on me, but I do recall in the old bad days when I used Java, I had to check for
this explicitly to prevent NPEs...)
I wonder what might be causing that.
Anyway, if the first thing after DB initialization I do is
===
def ectxt=ERXEC.newEditingContext()
def neweo=DBDataBlock.newInstance()
for (def cl=neweo.class;cl;cl=cl.superclass) println "- $cl"
println "created: ${neweo.storedValueForKey('actions')}"
ectxt.insertObject(neweo)
println "inserted: ${neweo.storedValueForKey('actions')}"
ectxt.saveChanges()
println "saved: ${neweo.storedValueForKey('actions')}"
ectxt.refaultObject(neweo)
println "refetched: ${neweo.storedValueForKey('actions')}"
===
I am getting
===
- class model.DBDataBlock
- class cz.ocs.model.OCSEnterpriseObject
- class er.extensions.eof.ERXGenericRecord
- class com.webobjects.eocontrol.EOGenericRecord
- class com.webobjects.eocontrol.EOCustomObject
- class java.lang.Object
created: null
inserted: null
saved: null
refetched: []
===
No, I do not override storedValueForKey (I do create the accessors, so wrong
“neweo.actions()” might be my fault; but storedValueForKey?!?)
Hmmm.... interesting. What on earth might be causing this?
Thanks,
OC
On 13. 4. 2016, at 19:51, Ricardo Parada <[email protected]> wrote:
> I would make sure the EO has ERXGenericRecord somewhere in its class
> hierarchy that the EO is inserted in the editing context before you do
> anything with it.
>
>
>
>> On Apr 13, 2016, at 1:18 PM, Chuck Hill <[email protected]> wrote:
>>
>> I suspect your code. If it is newly inserted and saved (and even unsaved I
>> think) they should be an empty array, not null.
>>
>>
>>
>>
>>
>>
>>> On 2016-04-13, 10:12 AM,
>>> "[email protected] on behalf of
>>> OC" <[email protected] on behalf
>>> of [email protected]> wrote:
>>>
>>> Hi there,
>>>
>>> with ERXEOControlUtilities.objectCountForToManyRelationship I have bumped
>>> into a weird problem — with newly created EOs it fails, yelling that “...
>>> is not a toMany relationship! Expected an NSArray, but got null” (exact
>>> copy below).
>>>
>>> Now, perhaps I do something wrong, but it seems to me it is perfectly
>>> normal in EOF that all to-manys of a newly created EO are null? At the very
>>> least, whenever I checked, they were.
>>>
>>> So far, the only fix I have found is to refault the newly created object
>>> immediately, which helps (fetch replaces those nulls by empty arrays), but
>>> it is pretty ugly:
>>>
>>> ===
>>> DBDataBlock bc=... create new EO and insert it into an EC ...
>>> ... set it up ...
>>> if (!ec.saveChanges()) return ERROR...
>>> bc.editingContext.refaultObject(bc) // <==== this helps. Without this
>>> line, to-manys are nulls now
>>> ===
>>>
>>> Is there any better solution?
>>>
>>> And what am I overlooking? To me, the check for null in
>>> objectCountForToManyRelationship looks like a bug.
>>>
>>> Thanks a lot,
>>> OC
>>>
>>> ===
>>> 18:53:43.124 WARN <er.extensions.appserver.ERXComponentRequestHandler>:
>>> Exception occurred while handling request:
>>> java.lang.IllegalArgumentException: The attribute named 'actions' in the
>>> entity named 'DBDataBlock' is not a toMany relationship! Expected an
>>> NSArray, but got null. //log:NSLog [WorkerThread0]
>>> [2016-4-13 18:53:43 CEST] <WorkerThread0>
>>> java.lang.IllegalArgumentException: The attribute named 'actions' in the
>>> entity named 'DBDataBlock' is not a toMany relationship! Expected an
>>> NSArray, but got null.
>>> at
>>> er.extensions.eof.ERXEOControlUtilities.objectCountForToManyRelationship(ERXEOControlUtilities.java:802)
>>> ...
>>> ===
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com
>>>
>>> This email sent to [email protected]
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/rparada%40mac.com
>>
>> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]