Problem jest następujący: w jednej z tabel mam kolumny których zawartość jest aktualizowana przez triggery (wyzwalane przez operacje na innej tabeli). Wiec kolumny te powinno sie traktować jako readonly, problem pojawia sie w momencie wykonywania metody save, która konstruje UPDATE zmieniający wartości ze wszystkich kolumn - nadpisując tym samym wartości z tych trigerowanych kolumn.
Mimo całej elastyczności AR nie udalo mi sie znalezc gotowej recepty na ten problem, a co wiecej ‘odkrylem’ z pewnym rozczarowaniem, że wykonanie metody update_attrubite takze kończy sie wyknaniem kompletnego UPDATE (co jak sobie wyobrażam przy większych tabelach może juz przerodzić sie w wąskie gardło)
Rozwiązania jakie przychodzą mi do głowy są dwa:
Wykorzystanie sztuczek na bazie, tak aby nie pozwolić na UPDATE tych kolumn readonly - może być troche karkołomne skoro triggery muszą mieć możliwość aktualizowania tych kolumn - ale myśle ze wykonalne
Zmodyfikowanie trochę efektu działania metody ‘attributes_with_quotes’ z base.rb - (po szczegóły zapraszam do kodu źródłowego AR)
Jakie jest wasze zdanie ? Może już podobny problem napotkaliście a rozwiązaniem jest jakaś tajemnicza trzecia droga …
Chyba zes cos dziwnego porobil bo ja nie mialem zadnych problemow. Po pierwsze napisz jaka baza. Po drugie wrzuc gdzies dumpa jej struktury. Po trzecie wrzuc gdzies kod trigerra.
Uzywalem PostgreSQLa i triggery tworzylem CREATE TRIGGER … BEFORE UPDATE… i wszystko sie dobrze aktualizowalo.
PS. Nie jestem pewien ale chyba w zadnym RDBMS nie ma czegos takiego jak kolumny “readonly”.
[quote=ruthrsc]Chyba zes cos dziwnego porobil bo ja nie mialem zadnych problemow. Po pierwsze napisz jaka baza. Po drugie wrzuc gdzies dumpa jej struktury. Po trzecie wrzuc gdzies kod trigerra.
Uzywalem PostgreSQLa i triggery tworzylem CREATE TRIGGER … BEFORE UPDATE… i wszystko sie dobrze aktualizowalo.[/quote]
hmm, wydaje mi się że zaszlo jakieś nieporozumienie
Postaram sie przedstawic genezę problemu jeszcze raz bardziej opisowo:
sa dwie tabele A i B w tabeli A mam kolumny A.counter1 i A.counter2, wartosci w tych kolumnach sa aktualizowane przez triggery podlaczone do tabeli B (i to jedyny ‘legalny’ sposob zmiany wartosci tych licznikow), teraz jezeli robie save() obiektu ktory jest zamapowany na tabele A powstała komenda sqlowa (UPDATE) aktualizuje takze counter1 i counter2 - co samo w sobie jest dosyc oczywiste. Niestety w tym przypadku skutkiem tego update’a jest nadpisanie wartosci w kolumnach A.counter1 i A.counter2 - a wg założeń zmiany w nich mają dokonywać tylko i wyłacznie triggery podpięte do tabeli B…
Czyli jak widzisz nie ma to nic wspolnego z dziwnościa bazy czy triggerow itd itp.
ja też o czymś takim nie słyszałem - choć akurat w postgresie dosyć łatwo do osiągnąć za pomocą rules.
Uzylem okreslenia ‘readonly’ jako skrótu myślowego w odniesieniu do kolumn counter1 i counter2 może stąd to zamieszanie.
Ok, teraz rozumiem (chyba).
Moze w takim razie napisac jakiegos RULE aby nie updateowal tych pol ?
Drugie rozwiaznie teoretycznie - moze nadpisac accessory dla tych pol aby wartosci szly w kosmos ?
Trzecie rozwiazanie: zrobic jakiegos wrappera dla obiektu A
[quote=ruthrsc]Ok, teraz rozumiem (chyba).
Moze w takim razie napisac jakiegos RULE aby nie updateowal tych pol ?[/quote]
jest to jakis pomysl - jak zaznaczylem w pierwotnym poscie bralem go pod uwage…
(utrudnieniem jest to ze trigger takze robi UPDATE…)
to nic nie daje jezeli nadpisze mutators dla tych pol to owszem nie bedzie mozna z zewnatrz wprost ustawic wartosci pól, ALE przy UPDATE i tak kolumny bedą zawarte w sql …
Rozwiazanie ktore dziala choc jest trickowe wpina sie w dzialanie metod create/update w base.rb, poprostu ingeruje w proces tworzenia komendy sql w taki sposob zeby nie pojawialy sie te zastrzezone pola - czyli zaimplementowalem pomysl nr 2. z pierwotnego maila.
