Cześć,
Potrzebuje wpłynąć na działanie AR tak, aby do każdego zapytania SQL które jest wykonywane na bazie danych dokładał jakiś tam warunek where.
Chodzi o to, żeby na jednej aplikacji przechowywać dane wielu klientów, w związku z tym, w każdej tabeli (albo prawie każdej) będzie pole client_id.
dzięki temu po zalogowaniu się usera, zostanie odczytana jego przynależność do danego klienta ustawiona w sesji i aplikacja będzie mogła działać tylko na danych tego klienta.
Z góry dzięki za pomoc
Krzysiek
PS
a może w ror jest jakieś inne magiczne podejście do tematu przechowywania danych (także konfiguracji) dla wielu klientów na jednej instancji bazy danych.
O jednym jeszcze pamiętaj: jeśli zamierzasz robić named_scope ze zmiennym parametrem (np. u Ciebie – id klienta), koniecznie podaj go jako lambdę – railsy w środowisku produkcyjnym cache’ują named_scope’y które nie są lambdą i możesz mieć śmieszne wyniki po postawieniu aplikacji na produkcji.
Mam jeszcze jedno małe pytanko,
Kiedyś używałem takiego plugina engines, który możliwa modyfikację kodu, bez modyfikacji oryginałów, tylko w osobnym katalogu się robi kopie jakiegoś pliku zamienia co się chce i to działa.
No i to jest cool, tyle tylko że chciałbym aby można było robić osobne modyfikacje dla każdego klienta, czyli w sesji jest przechowywane id clienta i w runtime uruchamiane są odpowiednie modyfikacje, osobne dla kazdego klienta.
chodzi o to, że nie wszystko da się sparametryzować, i czasami chciałbym, żeby dla dlanego klienta można było zmienić logikę biznesową, czy jakiś wgląd, czy cokolwiek innego. Dodatkowo już kompletnie zajebiste było by, gdyby można było tworzyć migracje db dla każdego z klientów, czyli np jak mamy tabelke
TAB1
aaa <-- pole wspólne dla kazdego klenta
bbb <-- pole wspólne dla kazdego klenta
cccc <-- pole wspólne dla kazdego klenta
dddd <-- pole wspólne dla kazdego klenta
pola dodatkowe
cust_prefix_additional_field1
cust_prefix_additional_field2
cust_prefix_additional_field3
no i teraz jak by model defaultowy działał na polach bez prefixu, a modyfikacje wprowadzone przez klienta modyfikowały by model i brały pod uwagę inne pola
Chodzi o to, żeby aplikacja była jedna, a każdy z potencjalnych klientów miał możliwość jej modyfikacji, na własną odpowiedzialnośc oczywiście
no i już na koniec pytanko o jakąś fajną bibliotekę do UI.
po pierwsze definicja interfejsu powinna być deklaratywna, po drugi musi być ładne (np jak ext js), a po trzecie ma działać także bez js w browserze, no i jeszcze powinny być jakieś helpery do tego …
[quote]chodzi o to, że nie wszystko da się sparametryzować, i czasami chciałbym, żeby dla dlanego klienta można było zmienić logikę biznesową, czy jakiś wgląd, czy cokolwiek innego. Dodatkowo już kompletnie zajebiste było by, gdyby można było tworzyć migracje db dla każdego z klientów, czyli np jak mamy tabelke
TAB1
aaa <-- pole wspólne dla kazdego klenta
bbb <-- pole wspólne dla kazdego klenta
cccc <-- pole wspólne dla kazdego klenta
dddd <-- pole wspólne dla kazdego klenta
pola dodatkowe
cust_prefix_additional_field1
cust_prefix_additional_field2
cust_prefix_additional_field3[/quote]
Ogólnie to zdecydowanie nie jest właściwa droga. Z pewnością da się te dodatkowe własności przechowywać w jakiejś uogólnionej formie, w ostateczności (client_id, name, value). Modyfikowanie schematu bazy danych oraz kodu aplikacji pod klienta to pomysł zdecydowanie karkołomny. Jeśli zamierzasz umożliwić użytkownikom modyfikowanie kodu, to zastanów się, czy masz jakikolwiek pomysł na zabezpieczenie swojej aplikacji przed złośliwymi modyfikacjami…
Hej,
CO do tych modyfikacji to nie wziołem tego tak z powietrza. Zawodowo zajmuje się czymś takim jak SAP R/3 (to taki ERP z przed 30 lat prawie )
Tam jest właśnie taki model, że aplikacja dostarczana jest z source codem do kleinta (kod jest w ABAPie, ABAP to taki 4GL też z przed 30 lat ).
Zmiany tak na szybko możemy wprowadzać przez
a) user exity, badi (takie miejsca w kodzie, które mają zdefiniowany interface)
b) zmiana dowolnego kody, ale musimy zarejestrować tą zmiane dostać klucz i wtedy tracimy gwarancje na ten fragment aplikacji
c) zmiany str tabel labo tak jak w punkcie b) albo przez tzw includy. Kazda tabelka ma doincludowany taki pusty include, jak go wypełnimy to mamy dodatkowe pola
Co do bezpieczeństwa to oczywiscie masz racje, takie coś wolno robić jeśli na jendej instancji systemu działa jedno przedsiebiorstwo, jak sobie zrobią kuku, to już ich sprawa.
Planuje taką małą aplikacyjke SaaS i to raczej dostarczyciel aplikacji wprowadzał by modyfikacje kodu dla każdego klienta, a nie sam klient. po prostu chciałbym utrzymywać jedną aplikacje a nie n aplikacji
Pozdrawiam
Krzysiek
To zmienia postać rzeczy
Generalnie jest to mocno niebanalne zagadnienie, z którym chętnie bym się zmierzył w praktyce.
Ale wymaga to naprawdę dogłębnego przemyślenia, w szczególności w kontekście dynamicznych własności Rubiego.
