https://bugzilla.wikimedia.org/show_bug.cgi?id=36431
--- Comment #6 from Daniel Kinzler <daniel.kinz...@wikimedia.de> 2012-05-07 13:18:35 UTC --- (In reply to comment #5) > Yeah, +1, that's basically what I said, but broken down better :) > > > using a list of objects representing updates jobs > > As long as the jobs get run immediately - would be very bad to have them end > up > in the jobque and not seeing the changes made right after save. Yes, of course. Such job objects may also be used for deferred updates, but it must be very clear which jobs have to run when. > > By the way - being able to cache the result of this check would be a reason > > to have non-mutable Content objects. > > Disagree. You can easily cache the validity and set it to unknown when a > change > that can impact it is made to the object. This would be even more effective > since you can ignore changes that don't impact it yes, but it's much more error prone and harder to maintain. but I don't insist on imutable objects :) > (you'd need to pass $isValid > to the constructor in the immutable case, which seems evil), no - immutable only says that isValid() (and all other getters) will always return the same value. Which can be cached internally, but may be initialized lazily. That's of course problematic in cases like this, when isValid() depends on external state (the database). > and you don't have > all the overhead of constantly creating new instances. We could have a mutator object, analogous to a StringBuffer in java. But whatever. > ... And it would not > work in the first place since you need to check right before doing the save, > unless you don't mind making the transaction significantly "less atomic" :) Well, if you want to avoid a race condition, yes. Then you can't cache the value anyway. But as I said, I think the race condition is acceptable, as long as it doesn't lead to permanent data corruption or loss. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
