[Nitro] Revisable -- is it the correct semantics??
william.full.moon at gmail.com
Wed Jun 28 07:44:26 EDT 2006
... This idea makes lots of sense really. Several wiki-s have the idea of
"minor change". You might want to store revision as a minor-number.
One other thing in a object-graph context, IF object "B" is contained-in or
aggregate-of object "A"
-->> Is it not also the case that owner item "A" has also been revised in
strict UML process parlance? Nominally, "A" is different as a container
From: nitro-general-bounces at rubyforge.org
[mailto:nitro-general-bounces at rubyforge.org] On Behalf Of James Britt
Sent: Wednesday, 28 June 2006 15:16
To: General discussion about Nitro
Subject: Re: [Nitro] Revisable -- is it the correct semantics??
Michael Fellinger wrote:
> On Wednesday 28 June 2006 12:25, James Britt wrote:
>>What was revised? You want the revision number to get upped on every
>>save, even if the item has not changed? Hmmm.
>>On the other hand, to do otherwise may introduce assorted questions
>>about determining when something has changed in a meaningful way
>>(i.e., some concept of a 'dirty' flag)
> Which also raises the question of partial updates - depending on what
> That is what i forgot - i think there's no problem with rising the
> revision on save... is there?
Well, the simplest thing may be to just assume that a call to 'save'
means there was a change (else why save it?), and the business logic just
has to take that into account. Then if someone doesn't want these
gratuitous revisions, they can implement some has_changed? behavior and skip
the save (perhaps intercept the call to save and do an update,
instead) if by whatever logic the object is not to be considered revised.
"I often work by avoidance."
- Brian Eno
Nitro-general mailing list
Nitro-general at rubyforge.org
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.5/377 - Release Date: 27-Jun-2006
More information about the Nitro-general