• 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: refaultObject( this )
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: refaultObject( this )


  • Subject: Re: refaultObject( this )
  • From: Jonathan Rochkind <email@hidden>
  • Date: Tue, 27 Apr 2004 13:58:21 -0500

Sure you can refault the EO which happens to be 'this' in the current scope. And it won't cause the problems you are worried about. But I'm not sure about your overall design.

Will "this" be a different reference before versus after the re-fault? Do I need to work with globalID's before and after the re-fault ? Will
that even work?

No worries. In the original Objective C, this _might_ have been a concern, but they had to change the way these things work for Java. You can't magically change a reference in Java, like you are thinking you could. In Java, 'faults' are even more purely a conceptual thing. A "fault" is still an object of the same EOEnterpriseObject implementing class used for full EOs of a given entity---it's just an object which does not have it's db-derived values filled in, which returns 'true' to isFault(), and which will automatically fill in all it's db-derived values as needed.


Whether the reference is to 'this' or to an object held in some other reference, before or after faulting the object will be the exact same Java object, just with it's state altered. A fault indeed still has a globalID, and will have the same globalID as any EO representing that same row in the db, whether fault or not.

You don't need to worry about exactly what you're worrying about, I don't think. On the other hand, I'm not sure your code will work the way you want for other reasons. I believe that applying changes to an EO which is a fault will cause the fault to 'clear' itself. Ie:

EOEnterpriseObject eo;
System.err.println( eo.isFault()); //let's say this returns false
eo.editingContext().refault( eo );
System.err.println( eo.isFault() ); //returns true, it's a fault now
eo.takeValueForKey( someValue, someKey );
System.err.println( eo.isFault() ); //I believe will return false. The act of setting a value will cause the fault to 'clear', that is load it's db-derived values.


I'm not sure if this causes a problem with your design, I'm not sure exactly what you are trying to do. Also beware, that a fault object, when clearing and loading db-derived data, will not neccesarily go to the db for that data! It can sometimes use an in-memory snapshot.

But you know what, I think that Apple, in the EOF book, provides some example code for how to do exactly what you are talking about. Of course, that doesn't mean the Apple example code actually works flawlessly; I haven't tried it myself. But let me look for what I think I remember seeing...
Take a look at:
http://developer.apple.com/documentation/WebObjects/Enterprise_Objects/UpdateStrategies/chapter_9_section_8.html
and
http://developer.apple.com/documentation/WebObjects/Enterprise_Objects/UpdateStrategies/chapter_9_section_9.html


Hmm, I'm not sure I am fully confident in the solutions proposed there though, actually. In particular, they are using the refaultObject strategy you came up with too---but again, a faulted object still might not use fresh-from-the-db values when the fault is cleared, and the implications of that seem troubling.

--Jonathan

At 11:30 AM -0700 4/27/04, Kent Harris wrote:
Can one invoke refaultObject() on "this"?

I have a complex optimistic locking failure recovery system wherein
many EO's implement their own recovery mechanisms.  The try/catch block
around the saveChanges, upon receiving an optimistic locking failure,
will under certain circumstances invoke a method (defined in an
abstract class that extends EOGenericRecord and is overridden in the
appropriate EO classes) similar to:

failedEO.optimisticLockingFailure( EOAdaptorOperation adaptorOperation
);

wherein the above method does something similar to:

NSMutableDictionary valuesInFailedSave =
adaptorOperation.changedValues();
NSDictionary changes = changesFromSnapshot(
editingContext().committedSnapshotForObject( this ) );

at which point I want to re-fault "this" and reapply only certain
attributes to the re-faulted object before saving changes once again
(effectively a last write wins but I have carefully chosen which
attributes are kept from the modified database entity and which are
kept from the editing-context's updated entity.)

editingContext().refaultObject( this );
... selectively apply newly calculated values based on the contents of
"valuesInFailedSave" and "changes" to "this".

Will "this" be a different reference before versus after the re-fault? Do I need to work with globalID's before and after the re-fault ? Will
that even work?


- Kent
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.


References: 
 >refaultObject( this ) (From: Kent Harris <email@hidden>)

  • Prev by Date: refaultObject( this )
  • Next by Date: Port Question
  • Previous by thread: refaultObject( this )
  • Next by thread: Port Question
  • Index(es):
    • Date
    • Thread