• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: rowDiffsForAttributes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rowDiffsForAttributes


  • Subject: Re: rowDiffsForAttributes
  • From: David Avendasora <email@hidden>
  • Date: Wed, 05 Mar 2014 10:38:51 -0500

Ramsey, I could kiss you!

On Mar 4, 2014, at 3:01 PM, David Avendasora <email@hidden> wrote:

It sounded promising, but unfortunately this did not fix it. It appears to be something I’m doing wrong.

Apparently what I was doing wrong was not actually using your solution on the EC that was the culprit.

In hindsight it all makes sense. If I create and save, or insert an EO into an EC and then not touch it again while I create dozens of nested ECs with nested ECs of their own, always local instancing the original EO into them, doing lots of work with multiple saves and reverts on each one using more an more memory, eventually Java says “Hey, you. Yes you! You pathetic weakly-linked snapshot of MYEntity hiding in the corner over there. You are garbage. Nobody wants (links to) you. Die. Die! DIE! DIEDIEDIEDIEDIEDIE….

er… 

oh. 

Right.

Setting the right EC to retain registered objects did the trick. MYEntity has proof he is loved now and nobody… ah hell, are you still here?

The EOF documentation points out the one-sided relationship of unchanged-EOs and ECs, but does not go into the possible implications for the EO itself (Page 81 of WebObjects Enterprise Objects Programming Guide):

<snip>
You usually do not need to worry about managing memory in an Enterprise Objects application, but this section may be interesting for advanced users.

EOEditingContexts use weak references to the EOEnterpriseObjects registered with them. EOEnterpriseObjects hold a strong reference to the EOEditingContext in which they are registered. These types of references prevent an EOEditingContext from being garbage collected while an EOEnterpriseObject still requires it. There are several exceptions:

  • EOEditingContexts hold all inserted, deleted, or updated objects by strong references. These strong references are cleared by the EOEditingContext methods saveChanges, revert, invalidateAllObjects, and reset. They may also be cleared by the EOEditingContext methods invalidateObjectsWithGlobalIDs, refaultObject, refreshObject, undo, and redo, depending on whether the changed state is or is not forcefully discarded.

  • EOEnterpriseObjects registered with an EOSharedEditingContext are always held by strong references.

  • You can force an EOEditingContext to hold strong references to all of its EOEnterpriseObjects by invoking either setInstancesRetainRegisteredObjects or setRetainsRegisteredObjects on an editing context in which no enterprise objects are registered. 

</snip>

You know, you could at least *pretend* to be surprised.

Pfft. Nobody around here is surprised at your ability to do things wrongly. It’s what you’re good at. Embrace it. Allow others to learn from your … talent.

No?

No.

grumble…

Cheer up! It could be worse, you could be one of the other Dave’s on the list; always having to say “No, not *that* Dave!"

Dave


On Mar 4, 2014, at 1:05 PM, Ramsey Gurley <email@hidden> wrote:

Are you using nested ecs? If you are, try ec.setRetainsRegisteredObjects(true).

https://github.com/wocommunity/wonder/pull/342

On Mar 4, 2014, at 9:35 AM, David Avendasora <email@hidden> wrote:

Hey all,

I’m getting the following exception (I added line breaks to make it digestible by any on the list):

IllegalStateException: rowDiffsForAttributes: snapshot in com.webobjects.eoaccess.EODatabaseOperation 
{
_dbSnapshot = {}; 
_entity = "MYEntity"; 
_newRow = 
{
whatsit = "PHONE";
whosit = false;
chuckIt = false;
id = 3451;
}; 
_object = "<com.nekesto.neo.model.MYEntity pk:"3451">"; 
_globalID = _EOIntegralKeyGlobalID[MYEntity (java.lang.Long)3451]; 
_databaseOperator = "EODatabaseUpdateOperator"; 
} does not contain value for attribute named chuckIt with snapshot key: chuckIt

I can see that the _dbSnapshot is completely empty and I know that that is what it’s complaining about. The object exists in the DB with a PK matching the id value, which matches up with the _object and the _globalID. How could the _dbSnapshot end up empty? What horribly-inappropriate thing have done? 

I have gone over everyplace I instantiate “MYEntity” and I’m never using the EO’s constructor, it’s always being done by ERXEOControlUtilities.createAndInsertObject(editingContext, “MYEntity”).

As far as I can tell I’m never crossing EC boundaries without localInstancing it. 

Is there anything else that can cause the _dbSnapshot to be empty?

I’m making use of multiple EOObjectStoreCoordinators, 1 each for two different EOModelGroups, but this code should only ever be using the defaultModelGroup in the defaultObjectStoreCoordinator. So I don’t *think* it has anything to do with that, but, well, I’m me and I do stuff all the time that future me is shocked at.

Dave

—————————————————————————————
WebObjects - so easy that even Dave Avendasora can do it!™
—————————————————————————————
David Avendasora
Senior Software Abuser
Nekesto, Inc.



 _______________________________________________
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

  • Follow-Ups:
    • Re: rowDiffsForAttributes
      • From: Chuck Hill <email@hidden>
    • Re: rowDiffsForAttributes
      • From: Ramsey Gurley <email@hidden>
References: 
 >rowDiffsForAttributes (From: David Avendasora <email@hidden>)
 >Re: rowDiffsForAttributes (From: Ramsey Gurley <email@hidden>)
 >Re: rowDiffsForAttributes (From: David Avendasora <email@hidden>)

  • Prev by Date: Re: rowDiffsForAttributes
  • Next by Date: Re: WebObjects-Projects?
  • Previous by thread: Re: rowDiffsForAttributes
  • Next by thread: Re: rowDiffsForAttributes
  • Index(es):
    • Date
    • Thread