🚀 go-pugleaf

Mirosław pisze:

> Mam taki problem. Otóż jest tabela z której korzystają użytkownicy
> (dodają nowe rekordy, modyfikują i zapisują rekordy) z tej samej
> tabeli korzystają też inne aplikacje, które w pewnych momentach,
> pobierają jakiś rekord robią krótkie obliczenia i zapisują go z
> kilkoma zmienionymi wartościami. Załóżmy teraz, że przed tym jak taka
> zew. aplikacja pobrała te dane, jakiś użytkownik pobrał je wcześniej i
> zaczął je edytować zapisując do bazy po tym jak zrobiła to zew.
> aplikacja. Sprawa oczywista - tracę ważne dane które wniosła zew.
> aplikacja. Jak najłatwiej ustrzec się tego błędu (w Django)?

Dodatkowa kolumna z numerem wersji danego wiersza + obsługa
konfliktów przy zapisywaniu, gdy się numery wersji nie zgadzają.

Ta obsługa będzie raczej ręczna - typu wyświetlasz userowi
że ktoś mu te dane "podstępnie" zmienił - teraz są takie, jego
są takie - "spróbuj jeszcze raz, cancel" :-)

Stach
-- 
http://stachlewski.info

On 10 Wrz, 12:40, Krzysztof Stachlewski <st...@fr.pl> wrote:
> Mirosław pisze:
>
> > Mam taki problem. Otóż jest tabela z której korzystają użytkownicy
> > (dodają nowe rekordy, modyfikują i zapisują rekordy) z tej samej
> > tabeli korzystają też inne aplikacje, które w pewnych momentach,
> > pobierają jakiś rekord robią krótkie obliczenia i zapisują go z
> > kilkoma zmienionymi wartościami. Załóżmy teraz, że przed tym jak taka
> > zew. aplikacja pobrała te dane, jakiś użytkownik pobrał je wcześniej i
> > zaczął je edytować zapisując do bazy po tym jak zrobiła to zew.
> > aplikacja. Sprawa oczywista - tracę ważne dane które wniosła zew.
> > aplikacja. Jak najłatwiej ustrzec się tego błędu (w Django)?
>
> Dodatkowa kolumna z numerem wersji danego wiersza + obsługa
> konfliktów przy zapisywaniu, gdy się numery wersji nie zgadzają.
>
> Ta obsługa będzie raczej ręczna - typu wyświetlasz userowi
> że ktoś mu te dane "podstępnie" zmienił - teraz są takie, jego
> są takie - "spróbuj jeszcze raz, cancel" :-)
>
> Stach
> --http://stachlewski.info

Dziękuję za odpowiedź.

Tak, mam w tabeli pole updated_date, po nim sobie "ręcznie" sprawdzam,
bo nic lepszego na razie nie wymyśliłem.

A takie pytanie:
Jeśli user edytuje dane formularzem wygenerowanym na podstawie modelu,
w którym wyłączę parę pól, to rozumiem, że nawet gdy będzie zapisywał
starymi danymi do już zaktualizowanych to te wyłączone dane nie będą
zaktualizowane i zostaną w takim stanie jak je te moje aplikacje
zewnętrzne zmodyfikowały?

A teraz na odwrót, jeśli wezmę:
e = MyModel.objects.get(pk=1)
e.some_data = 1
e.save()
to zostaną zaktualizowane wszystkie dane czy tylko "some_data"?

Mirek.

Mirosław pisze:

> Tak, mam w tabeli pole updated_date, po nim sobie "ręcznie" sprawdzam,
> bo nic lepszego na razie nie wymyśliłem.

No ja bym jednak stawiał na numer wersji, bo ta data, to się może
w jakimś skrajnym przypadku okazać identyczna dla dwóch kolejnych
transakcji i co wtedy...

> A takie pytanie:
> Jeśli user edytuje dane formularzem wygenerowanym na podstawie modelu,
> w którym wyłączę parę pól, to rozumiem, że nawet gdy będzie zapisywał
> starymi danymi do już zaktualizowanych to te wyłączone dane nie będą
> zaktualizowane i zostaną w takim stanie jak je te moje aplikacje
> zewnętrzne zmodyfikowały?

Raczej nie powinien ich ruszać. Bo przecież o nich nie wie.
Ale jak wstawisz nowy obiekt tego typu i zrobisz save,
to tamte niezdefiniowane w modelu pola zostaną wypełnione
domyślnymi wartościami na poziomie bazy.

> A teraz na odwrót, jeśli wezmę:
> e = MyModel.objects.get(pk=1)
> e.some_data = 1
> e.save()
> to zostaną zaktualizowane wszystkie dane czy tylko "some_data"?

Tutaj tylko some_data. ORM sobie trzyma wewnętrznie, które pola
były zmieniane i tylko na nich robi update.
Tylko, że jak ty chcesz robić takie fiku-miku ;-)
to:

Potrzebujesz zrobić:
UPDATE costam SET pole=wartosc WHERE nr_wersji=NNN;
następnie sprawdzić czy UPDATE zmienił jakąś krotkę,
i jeśli nie zmienił, to stwierdzić, że coś ci ją nadpisało/skasowało.
A tego w django chyba nie zrobisz ładnie.

Opcjonalnie otwierasz transakcję,
robisz najpierw SELECT ... FOR UPDATE.
Patrzysz sobie ręcznie czy wersja jest OK
i podejmujesz decyzję co dalej (byle szybko :-)
Albo zapisujesz nowymi wartościami,
albo kończysz transakcję
niczego nie zmieniając i wywalasz błąd userowi.

To już chyba jest wspierane przez Django.
Nie jestem pewien, ale jakiś ticket znalazłem:
http://code.djangoproject.com/ticket/2705

No tyle, że robisz w sumie niepotrzebny SELECT.

Stach
-- 
http://stachlewski.info

On Sep 10, 11:15 am, Mirosław <miroslaw....@gmail.com> wrote:
> Witam,
>
> Mam taki problem. Otóż jest tabela z której korzystają użytkownicy
> (dodają nowe rekordy, modyfikują i zapisują rekordy) z tej samej
> tabeli korzystają też inne aplikacje, które w pewnych momentach,
> pobierają jakiś rekord robią krótkie obliczenia i zapisują go z
> kilkoma zmienionymi wartościami. Załóżmy teraz, że przed tym jak taka
> zew. aplikacja pobrała te dane, jakiś użytkownik pobrał je wcześniej i
> zaczął je edytować zapisując do bazy po tym jak zrobiła to zew.
> aplikacja. Sprawa oczywista - tracę ważne dane które wniosła zew.
> aplikacja.

Użyj transakcji. W takich przypadkach baza ci pojedzie wyjątkiem
IntegrityError.

Bart Ogryczak pisze:
> On Sep 10, 11:15 am, Mirosław <miroslaw....@gmail.com> wrote:
>> Witam,
>>
>> Mam taki problem. Otóż jest tabela z której korzystają użytkownicy
>> (dodają nowe rekordy, modyfikują i zapisują rekordy) z tej samej
>> tabeli korzystają też inne aplikacje, które w pewnych momentach,
>> pobierają jakiś rekord robią krótkie obliczenia i zapisują go z
>> kilkoma zmienionymi wartościami. Załóżmy teraz, że przed tym jak taka
>> zew. aplikacja pobrała te dane, jakiś użytkownik pobrał je wcześniej i
>> zaczął je edytować zapisując do bazy po tym jak zrobiła to zew.
>> aplikacja. Sprawa oczywista - tracę ważne dane które wniosła zew.
>> aplikacja.
> 
> Użyj transakcji. W takich przypadkach baza ci pojedzie wyjątkiem
> IntegrityError.

Rozwiń, proszę.

Transakcja nic tu nie daje. Chyba, że na poziomie serialized
*i* jeśli do tego będziesz ją trzymał cały czas otwartą
w trakcie gdy user edytuje sobie te dane.

Stach
-- 
http://stachlewski.info

Krzysztof Stachlewski pisze:

> Transakcja nic tu nie daje. Chyba, że na poziomie serialized

[poprawka] Oczywiście miało być "serializable".

Stach
-- 
http://stachlewski.info

On Sep 10, 6:01 pm, Krzysztof Stachlewski <st...@fr.pl> wrote:
> Bart Ogryczak pisze:
>
> > On Sep 10, 11:15 am, Mirosław <miroslaw....@gmail.com> wrote:
> >> Witam,
>
> >> Mam taki problem. Otóż jest tabela z której korzystają użytkownicy
> >> (dodają nowe rekordy, modyfikują i zapisują rekordy) z tej samej
> >> tabeli korzystają też inne aplikacje, które w pewnych momentach,
> >> pobierają jakiś rekord robią krótkie obliczenia i zapisują go z
> >> kilkoma zmienionymi wartościami. Załóżmy teraz, że przed tym jak taka
> >> zew. aplikacja pobrała te dane, jakiś użytkownik pobrał je wcześniej i
> >> zaczął je edytować zapisując do bazy po tym jak zrobiła to zew.
> >> aplikacja. Sprawa oczywista - tracę ważne dane które wniosła zew.
> >> aplikacja.
>
> > Użyj transakcji. W takich przypadkach baza ci pojedzie wyjątkiem
> > IntegrityError.
>
> Rozwiń, proszę.
>
> Transakcja nic tu nie daje. Chyba, że na poziomie serialized
> *i* jeśli do tego będziesz ją trzymał cały czas otwartą
> w trakcie gdy user edytuje sobie te dane.

No niestety, jak chce się mieć gwarancje spójności to do tego się
sprowadza.
Ewentuajnie można zrobić tak jak w Tracu -- wykrywać, że zostało
zmienione i nie pozwalać userowi na zapisanie.

Mirosław wrote:
> Witam,
> 
> Mam taki problem. Otóż jest tabela z której korzystają użytkownicy
> (dodają nowe rekordy, modyfikują i zapisują rekordy) z tej samej
> tabeli korzystają też inne aplikacje, które w pewnych momentach,
> pobierają jakiś rekord robią krótkie obliczenia i zapisują go z
> kilkoma zmienionymi wartościami. Załóżmy teraz, że przed tym jak taka
> zew. aplikacja pobrała te dane, jakiś użytkownik pobrał je wcześniej i
> zaczął je edytować zapisując do bazy po tym jak zrobiła to zew.
> aplikacja.

Jak na razie wszyscy proponowali blokowanie optymistyczne
http://martinfowler.com/eaaCatalog/optimisticOfflineLock.html
W zależności od tego jak dokładnie działa Twoja aplikacja możesz też
spróbować blokowania pesymistycznego (z ewentualnym time-outem)
http://martinfowler.com/eaaCatalog/pessimisticOfflineLock.html

Pozdrawiam,
Wojciech Malinowski

On Sep 10, 1:10 pm, Mirosław <miroslaw....@gmail.com> wrote:
> On 10 Wrz, 12:40, Krzysztof Stachlewski <st...@fr.pl> wrote:
>
>
>
>
>
> > Mirosław pisze:
>
> > > Mam taki problem. Otóż jest tabela z której korzystają użytkownicy
> > > (dodają nowe rekordy, modyfikują i zapisują rekordy) z tej samej
> > > tabeli korzystają też inne aplikacje, które w pewnych momentach,
> > > pobierają jakiś rekord robią krótkie obliczenia i zapisują go z
> > > kilkoma zmienionymi wartościami. Załóżmy teraz, że przed tym jak taka
> > > zew. aplikacja pobrała te dane, jakiś użytkownik pobrał je wcześniej i
> > > zaczął je edytować zapisując do bazy po tym jak zrobiła to zew.
> > > aplikacja. Sprawa oczywista - tracę ważne dane które wniosła zew.
> > > aplikacja. Jak najłatwiej ustrzec się tego błędu (w Django)?
>
> > Dodatkowa kolumna z numerem wersji danego wiersza + obsługa
> > konfliktów przy zapisywaniu, gdy się numery wersji nie zgadzają.
>
> > Ta obsługa będzie raczej ręczna - typu wyświetlasz userowi
> > że ktoś mu te dane "podstępnie" zmienił - teraz są takie, jego
> > są takie - "spróbuj jeszcze raz, cancel" :-)
>
> > Stach
> > --http://stachlewski.info
>
> Dziękuję za odpowiedź.
>
> Tak, mam w tabeli pole updated_date, po nim sobie "ręcznie" sprawdzam,
> bo nic lepszego na razie nie wymyśliłem.
>
> A takie pytanie:
> Jeśli user edytuje dane formularzem wygenerowanym na podstawie modelu,
> w którym wyłączę parę pól, to rozumiem, że nawet gdy będzie zapisywał
> starymi danymi do już zaktualizowanych to te wyłączone dane nie będą
> zaktualizowane i zostaną w takim stanie jak je te moje aplikacje
> zewnętrzne zmodyfikowały?

Nie. Django przy wywolaniu metody save robi update na wszystkie pola
zdefiniowane w modelu.

>
> A teraz na odwrót, jeśli wezmę:
> e = MyModel.objects.get(pk=1)
> e.some_data = 1
> e.save()
> to zostaną zaktualizowane wszystkie dane czy tylko "some_data"?
>

Zostana zaktaulizowane wszystkie pola zdefiniowane w modelu django.
Jezeli chcesz aktualizowac tylko wybrane pola moze to robic za pomocą
metody update queryseta ( nie obiektu)
czyli .

MyModel.objects.filter(pk=1).update(some_data=1)


polecam pobawic sie  za pomoca : python manage.py shell
from django.db import connection
print connection.queries

Jezeli aplikacja jest w trybie debug to w connection.queries bedziesz
mial ostatnio wykonane przez django zapytania .