Re: Custom Entity Classes
Re: Custom Entity Classes
- Subject: Re: Custom Entity Classes
- From: Chuck Hill <email@hidden>
- Date: Fri, 15 Jun 2012 09:11:43 -0700
Hi Doug,
On 2012-06-15, at 8:50 AM, doug andrews wrote:
> OK, I'm not sure why this works, but it seems to patch the problem.
>
> I have a to one relationship between the CUSTOMER and ADDRESS table. (Every customer has one mandatory address.)
> Both Address and Customer have custom entity classes. (Customer.java and Address.java.)
> The relation in the model for the customer entity is called "address".
> There is a non-null field in address called "zip".
>
> I have an Customer EO variable called custEO.
>
> Sometimes the line below will fail with a null pointer.
> Only sometimes, when the app is busy with 80 or more users.
>
> System.out.println(custEO.address().zip());
>
> But these lines won't.
>
> Address addEO = custEO.address();
> System.out.println(addEO.zip());
>
> Does anyone know why this would be?
My best guess would be lack of proper EOEditingContext locking.
Second guess would be lack of property EODatabaseContext or below locking (best to lock the root object store if you want to be safe).
> I'd like to fix this in my entity classes instead of patch the code everywhere the key path goes more that one deep.
Speaking from experience :-), that won't work. You are just addressing the symptom. Patch all of these and the problem will then pop up elsewhere.
Back to the commandments.
Chuck
> On Jun 9, 2012, at 9:00 PM, doug andrews wrote:
>
>> I think we're breaking one or more commandment.
>> I see if that fixes our issue.
>> Thanks.
>>
>>
>> On Jun 8, 2012, at 8:34 PM, Chuck Hill wrote:
>>
>>> Hi Doug,
>>>
>>>
>>> On 2012-06-08, at 9:35 AM, doug andrews wrote:
>>>
>>>> Most of my entities are of class EOGenericRecord.
>>>> I do have a few custom entity classes that extend EOGenericRecord.
>>>
>>> Either your app is really simple, or you are doing it wrong. :-)
>>>
>>>
>>>> Sometimes, not always, the accessor methods for the "to one" relationships return null, even though I know the relationship exists. This usually only occurs when the app has 70 or more sessions running.
>>>
>>> That sounds more like you are breaking EOF commandments and getting EOF state corruption due to concurrency conflicts.
>>>
>>>
>>>> The code for these custom entities was generated by the old EOModeler app.
>>>> They simply return storedValueForKey.
>>>
>>> That sounds correct.
>>>
>>>
>>>> The foreign key of the relationship is marked as "not null" in the model, but the relationship is marked as "optional". I know this is probably wrong, but the old EOModeler app let you get away with this, and i'm sure stuff would break if i changed it now.
>>>>
>>>> To get the related entity from an EO that is of type EOGenericRecord, I simply use valueForKey, and this never seems to return null. Since this always works, should my accessor methods in my custom entity classes return valueForKey instead of storedValueForKey? Would that fix my problem?
>>>
>>>
>>> No, that will cause infinite recursion as valueForKey will call your accessor methods which will call valueForKey which will call....
>>>
>>>
>>>
>>> Chuck
>>>
>>>
>>> --
>>> Chuck Hill Senior Consultant / VP Development
>>>
>>> Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
>>> http://www.global-village.net/gvc/practical_webobjects
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/gvc/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden