Chris F Clark schreef:

> If you have a fixed database, and you do two selects which specify the
> same sets of fields to be selected and the same keys to select records
> with, one expects the two selects to return the same values.

When your "fixed" means read-only, or (fully) locked, then yes.

Modern databases also have modes without locks, so without special
attention (like maybe your "fixed") the two selects do not necessarily
return the same set of records.


> Further, if you
> do an update, you expect certain fields of certain records to change
> (and be reflected in subsequent selects).

Doesn't your "fixed" block updates?


> However, therein lies the rub, if you do a select on some records, and
> then an update that changes those records, the records you have from
> the select have either changed or show outdated values.

Not necessarily outdated: values can be fixed in time for a purpose.
Example: calculating interest is done once per day, but the whole
process takes more than a day.

Some systems implemented a lock plus requery just before the update, to
check for unacceptable changes in the stored data; this to prevent
having to keep locks while waiting.


> If there is
> some way to refer to the records you first selected before the update,
> then you have an aliasing problem, but maybe one can't do that.  One
> could also have an aliasing problem, if one were allowed to do two
> updates simultaneously, so that one update could changed records in
> the middle of the other changing the records.

Some databases allow you to travel back in time: run this query on the
data of 1 year ago. All previous values are kept "behind" the current
value.

-- 
Affijn, Ruud

"Gewoon is een tijger."


-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to