Ha! Seems I have found the culprit. Thanks a lot for the advice >> changing type between Integer and Long?
pursuing it further, it looks like the darned BigDecimal thing's equals work in a pretty weird way, considering exactly same values, just stored with a different scale, well, non-equal (this is actually documented suggesting using compareTo instead; but I bet EOF uses equals internally — it could hardly do otherwise —, and therefore same values are stored unnecessarily. Oh sigh.) Thanks again! OC > On 14 Aug 2018, at 8:13 PM, ocs@ocs <o...@ocs.cz> wrote: > > Chuck, > >> On 14 Aug 2018, at 7:37 PM, Chuck Hill <ch...@gevityinc.com >> <mailto:ch...@gevityinc.com>> wrote: >> >> Could there be some place in your code that is changing type between Integer >> and Long? EOF would see that as a value change, though the value logged >> would appear the same. > > thanks a lot, but actually I use BigDecimals for the attribute, and my > accessor methods look like this: > > === > public java.math.BigDecimal originalAmount() { > return (java.math.BigDecimal) > storedValueForKey(_DBAuction.ORIGINAL_AMOUNT_KEY); > } > public java.math.BigDecimal getOriginalAmount() { originalAmount() } > public void setOriginalAmount(java.math.BigDecimal value) { > takeStoredValueForKey(value, _DBAuction.ORIGINAL_AMOUNT_KEY); > } > === > > given which I think it would not be the culprit, unless I am overlooking some > trick. Weird. > > Let me please check whether I recall properly how the sync betw. EC and > snapshot works. Let's assume there's an enterprise object “eo” with an > attributes “foo“ and “bar“. Let's assume x.foo=="a" at the moment. Now > > 1. user A starts a R/R loop and reads in eo to work with; > 2. user B starts his own R/R loop, changes eo.foo to "b", savesChanges and > ends its R/R loop; > 3. user A — still in the same R/R loop of 1 — now > > 3a. makes some irrelevant changes without ever touching eo, and saves them. > Since eo did never got into his updated object list, it's all right; > > 3b. he changes the eo.bar attribute (never changing eo.foo anyhow), and saves > changes. > > In this case, oops! eo.foo gets rewritten in the database to the old value of > "a", for eo is amongst A's updated object list, and the live eo.a value > differs from the snapshot — A's live value of eo.a would have been updated > from snapshot at the end of the R/R loop, when EC unlocks; but that's in this > case too late. > > Right, is this the behaviour, or am I overlooking something here? > > Thanks again a very big lot, > OC > >> >> From: Webobjects-dev >> <webobjects-dev-bounces+chill=gevityinc....@lists.apple.com >> <mailto:webobjects-dev-bounces+chill=gevityinc....@lists.apple.com>> on >> behalf of "ocs@ocs" <o...@ocs.cz <mailto:o...@ocs.cz>> >> Date: Tuesday, August 14, 2018 at 10:26 AM >> To: "webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>" >> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >> Subject: updates to same value: why they happen? >> >> Gentlemen, >> >> my code logs out all database changes in the >> databaseContextWillPerformAdaptorOperations delegate method. >> >> Lately from these logs I have found that one of my applications tends to >> pretty often update an attribute to the same value it used to have before, >> like this: >> >> === >> 249 /tmp> fgrep "UPDATE on 'DBAuction' ((uid = 1002533)" LOG >> 13:38:25.214|WorkerThread7 - 4: UPDATE on 'DBAuction' ((uid = 1002533)) >> 1{originalAmount:11058} >> 09:02:58.136|WorkerThread2 - 1: UPDATE on 'DBAuction' ((uid = 1002533)) >> 1{originalAmount:11058} >> 09:55:57.970|WorkerThread5 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) >> 1{originalAmount:11058} >> 10:09:37.079|WorkerThread22 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) >> 1{originalAmount:11058} >> 10:14:31.399|WorkerThread11 - 2: UPDATE on 'DBAuction' ((uid = 1002533)) >> 1{originalAmount:11058} >> 251 /tmp> >> === >> >> Can you see what might be the culprit? >> >> I understand this would happen if the value in the object itself does not >> change, whilst the value in the snapshot would; but how could change the >> attribute value of the snapshot without being written out to the database >> (which, if happened, would be logged as well)? >> >> Thanks a lot for any advice, >> OC
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
