Re: data integrity
От | Janning Vygen |
---|---|
Тема | Re: data integrity |
Дата | |
Msg-id | 0111061224020G.26334@janning обсуждение исходный текст |
Ответ на | Re: data integrity (Martín Marqués <martin@bugs.unl.edu.ar>) |
Ответы |
Re: data integrity
|
Список | pgsql-general |
Am Dienstag, 6. November 2001 00:17 schrieb Martín Marqués: > On Lun 05 Nov 2001 18:06, you wrote: > > Hi > > > > I'm using postgresql to manage a web site. > > > > Problem: How are people dealing with data integrity issues such > > as stale data when writing web-based apps? For instance: > > > > The value of X is 7. > > > > Step (1) User A selects X. > > Step (2) User B selects X. > > Step (3) User A updates X to 8. > > Step (4) User B updates X to 10 under the assumption that X is > > still 7. > > Lock it with a SELECT ...... FOR UPDATE. The rows that are going to > be updated will be locked, but not the entire table. :-) I dont think that FOR UPDATE helps in this situation, but it might be a misunderstanding. FOR UPDATE locks the rows of the table for an update. right. but it removes the lock if the transaction commits. In a web based application you cant enforce a transaction between the sending of a form and the exceuting of a submit. Its an application problem: the data i see in my frontend are never realtime. they might have change in the last seconds. But who cares. If i want to have a value of 8 and another one wants a value of 10 its a question of whom granting write access. janning > > In some scenarios, user B should be prevented from updating. > > > > Solutions (that I'm considering): > > > > (1) Timestamp: Have a timestamp for every row in every table, > > which automatically changes when a row is inserted or updated, or > > > > (2) Cache: Similarly, cache the user's selected data on the > > server side (every tuple from the original select) and compare > > when the user attempts to update, or > > > > (3) Squash: modify only those fields in the row that need > > updating (instead of the entire row) and whatever happens > > happens. > > > > Has anyone solved this 'stale data' problem before? > > > > Does this fall into a family of problems that has an existing > > (trivial) solution? Also, is it the responsibility of the > > application server to deal with the scenario above or should the > > application itself be responsible? > > saludos... ;-) -- Planwerk 6 /websolutions Herzogstraße 86 40215 Düsseldorf fon 0211-6015919 fax 0211-6015917 http://www.planwerk6.de
В списке pgsql-general по дате отправления: