Usually in a domain model, you'll have objects, and those objects will have properties that are mutable and properties that are immutable - for instance, a instance id/name will be immutable, while some other properties (specially properties that depend on relationships with other objects) can vary in the lifetime of an objectSo, in the usual scenario where multiple clients are accessing the same data store, your ORM tool will usually model columns as properties and relationships as lists, in the mutual understanding that any mutable property might be outdated in the client - that is, they only represent caches of the values of the properties. However, in many circumstances, one wants to do an operation that might require the actual state of the mutable properties, otherwise the operation might fail or produce data corruption, so in those cases you'll attempt a lock in the row in question, and if the row has already changed then you cancel or abort. In any case, the operation is done off the client application.At some point I have to ask a question (oddly enough, its turning out to be surprising hard!), so I guess the question would be: is there any scenario where it's useful to keep mutable properties cached in domain objects for anything else than informational purposes? After all, if there are relationships that we care for, say we want to traverse the neighbours of some object, we'll want to do that with their real (not cached) states, which would involve a database transaction, or some other means to do the process atomically (maybe map reduce?).
Is there any scenario where it's useful to keep mutable properties cached in domain objects for anything else than informational purposes?
orm;domain model;immutability