On 19/11/2010, at 11:27 AM, Dmytrii Nagirniak wrote:
But as far as I understand Chris needs to ensure that there are no
stale objects in the middle of an action (not user's one but a
system's).
That's not even theoretically possible in a parallel system. All you
can do is code each
transaction semantically (add 1 to X rather than set X to old-X+1) and
then rely on
database serialisation to make it work. In order to reduce deadlocks,
you can use
intent-update locks (which AR's :lock gives you) or just ensure that
multi-record
updates are ordered (i.e. if you update A then B in one transaction,
you never update
B then A in another).
With long-polling or websockets, you could potentially notify the user
that the record
they're seeing has been updated, but you'd have to think that through
from a XP point
of view.
However, I don't think that's what Chris was concerned about. It seems
to me he was
worried that while I'm looking at some data and perhaps changing it,
but haven't yet
submitted my changes, someone else will submit a change that make my
changes
invalid. The correct answer is to detect that using versioning or row-
value checksums,
where the check value is hidden in the form I will submit, and must
match if my changes
are to be accepted.
The nice thing about doing this with checksums (as opposed to
versions) is that if the
record is large, and I'm only looking at a subset of the fields, I can
have a checksum
over just those fields, rather than the whole record. When I submit,
the record is re-fetched
and those fields re-checksummed. As long as *nothing I was looking at*
has changed,
my update is still valid. In most applications. YMMV. You might not
have encountered a
situation where this was even possible... but for example, the Claims
table in an insurance
app might well have a hundred fields, and those will never all be
shown at the same time.
You could break the record into separate records and use row versions
for each, but
then your UI is leaking into your schema.
Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design
--
You received this message because you are subscribed to the Google Groups "Ruby or
Rails Oceania" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rails-oceania?hl=en.
