Ramsey,
On 19. 2. 2015, at 19:15, Ramsey Gurley <[email protected]> wrote:
> You do a lot of weird stuff :)
Actually _this_ should not be weird, this should be quite a normal code; the
only requirement is that check-and-save, i.e., conceptually,
===
if (eo.someRelationship().someAttribute()<newAttributeValue) {
def
new=EOUtilities.createAndInsertInstance(eo.editingContext(),'SomeRelationshipTarget')
new.someAttribute=newAttributeValue
eo.editingContext().saveChanges()
}
===
so that I can be absolutely sure that no two users from two sessions may store
the same attribute value.
The current application is running single-instance, which makes the problem
somewhat easier, but surprisingly, not easy by far, given
WOAllowsConcurrentRequestHandling=YES.
Is there a well-known pattern for this?
(Hmmm... now it occurred to me, perhaps I might set up an UNIQUE db restraint?
That would probably simplify the code mightily, _and_ work for multi-instance
case just as well...)
Other parts of my code though -- eg. the primary-key-based „static“ objects
which in the old version I, triple alas, can't get rid of for time reasons --
definitely are, and then some :)
> Have you installed jadclipse yet?
> https://wiki.wocommunity.org/display/documentation/Useful+Eclipse+Plugins
> You can probably answer a lot of your questions just looking at the source.
I can hardly install the thing, for I am not using Eclipse anymore -- can't
speak for other platforms, but on Mac, I have never seen a worse IDE.
Nevertheless thanks again, as soon as I have some extra time I'll check the
sources (along with those of FreshnessExplorer).
> If I had this problem, I’d probably first try providing my own EC subclass
> through the ERXEC factory with deleteObject(eo) overridden. If that didn’t
> catch it, then I’d dig around in the WO source to find where in the save
> changes process owns destination comes into play.
The WO sources are available (though perhaps unofficially)? I have thought
Apple keeps them well locked out. How can one get them?
Thanks again a very big lot,
OC
> On Feb 19, 2015, at 7:48 AM, OC <[email protected]> wrote:
>
>> Hello there,
>>
>> occassionally, an object gets deleted which should not be. Now, just before
>> "ec.saveChanges()" I am logging out
>>
>> ===
>> lognow "saving INS:$ec.insertedObjects.count
>> UPD:$ec.updatedObjects.count DEL:$ec.deletedObjects.count"
>> ===
>>
>> and in my "databaseContextWillPerformAdaptorOperations" delegate method I am
>> logging out all the operations, and the results I sort of can't decode:
>>
>> ===
>> 14:38:16.299|WorkerThread14 --- saving INS:2 UPD:4 DEL:0
>> ... about to perform 4 DB operations
>> - 1: INSERT on 'DBPriceOffer' 8{validOffer:false,
>> sheetConfirmed:<com.webobjects.foundation.NSKeyValueCoding$Null>,
>> uid:1022548, auction_id:1000233,
>> amount:<com.webobjects.foundation.NSKeyValueCoding$Null>, price:1142,
>> creationDate:2015-02-19 13:38:15 Etc/GMT, creator_id:1000058}
>> - 2: INSERT on 'DBAudit' 8{creator_id:1000058, uid:1031224,
>> creationDate:2015-02-19 13:38:15 Etc/GMT, kind:8, auction_id:1000233,
>> title:cenov? návrh 1142 CZK/MWh, aktuální auk?ní cena 11…,
>> market_id:1000001, ipAddress:212.27.219.66}
>> - 3: UPDATE on 'DBAuction' ((uid = 1000233) and (commodityTimechunksString =
>> 'LVO-1022542: 1140/null (true/0) 2015-02-19 13:38:10 Etc/GMT BY EONenergie
>> (1000048) USR EONenergie (1000048) ===> prc 1139 CU RWEEnergie USR
>> RWEEnergie BR Hurtova (RB false)') and (commodityPriceSelectionType =
>> 1022547)) 1{commodityTimechunksString:LVO-1022547: 1139/null (true/0)
>> 2015-02-19 13:38:1…}
>> - 4: DELETE on 'DBUserAuction' ((user_id = 1000058) and (auction_id =
>> 1000233))
>> ===
>>
>> Those inserts make complete sense, no problem with them at all. They should
>> happen, and their contents is OK.
>>
>> There were 4 updates in editing context, but there's only one update
>> operation. Now, do please correct me if I am wrong, but I understand the
>> editing context saves all changes (regardless the value might be same as
>> before) and consider them “updates”; when saving though, it compares them
>> against the snapshot and makes an operation only if the value differs. Thus,
>> UPD:4 make sense too, and the one update which changes only a string
>> attribute 'commodityTimechunksString' of auction 1000233 makes complete
>> sense. It should happen, and the contents is OK.
>>
>> The 4th operation is the problem. It should not happen.
>>
>> From the fact just before save ec.deletedObjects.count==0 (DEL:0) I infer
>> that EOF decided to delete the object based on ownership or cascade deletion
>> rules. Given nothing other got deleted, it _must_ be ownership -- the object
>> having been removed from some owned relationship. There indeed are two of
>> them.
>>
>> Now, the trick is that I am pretty sure I am _not_ removing any of these
>> object from either of the relationships: at the very least, I can't recall I
>> would (the DBUserAuction objects are not intended to be ever deleted, unless
>> the user or auction to which they belong are deleted too), and nor I can
>> find any usage of removeObjectFromBothSides... nor other APIs with the
>> relationships in question.
>>
>> Is there some trick to catch the code which actually causes the deletion?
>>
>> I've tried to observe
>> EOEditingContext.ObjectsChangedInEditingContextNotification, but it seems it
>> does not get posted even if I add a removeObjectFromBothSides... manually to
>> test.
>>
>> Will be grateful for any advice,
>> OC
>>
>>
>> _______________________________________________
>> 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/rgurley%40smarthealth.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]
