Dnia środa, 21 września 2005 16:21, konrad rzentarzewski napisał:

11/09/05, messie from [ Jakub Wartak ] ...

...

I mam pierwsze pytanie: czy ktos planuje zrobienie mozliwosci dodawania roznych *dodatkowych* zapytan w przypadku dodania/usuniecia kompa/usera/urzadzenia/etc ?

Bo byloby mi to potrzebne w kilku lokalizacjach ( integracja z postfixem na sqlu na innej maszynie + integracja z czyms takim jak netmrg/podobne ), i oczywiscie dopisze troche kodu php jesli bedzie bardzo potrzebne, tylko nie chcialbym wynajdywac kola na nowo ;)

dobrym rozwiązaniem będzie dla ciebie zastosowanie funkcji składowanych i triggerów (ew. widoków i zasad, jeśli struktury będą proste), co determinuje użycie postgresa, jako silnika db, ale ma kilka *bardzo* istotnych zalet:

• ponieważ lms nie planuje użycia funkcji/triggerów/widoków, nie będzie kolidować z "głównym wydaniem"
• ponieważ lms rozwija się szybko i wydaje 10 nowych wersji w ciągu roku będziesz mógł zrobić upgrade bez martwienia się o kompatybilność ze swoimi modyfikacjami
• ponieważ lms ma w zwyczaju zmieniać strukturę bazy z wydania na wydanie przy ewentualnym upgradzie będziesz musiał tylko dostosować swoje funkcje/widoki, a nie martwić się o zmiany w aplikacjach współpracujących

No wlasnie tez myslalem juz nad triggerami, tyle ze ( w przewazajacej ilosci przypadkow jest juz MySQL ). Hm, pomysle nad upgradem do 5.0 :/

pozostałe modyfikacje, czyli swoje części systemu rób poza lmsem, bo ten nie nadaje się jeszcze do modułowej rozbudowy (tj. funkcje core, na których mógłbyś chcieć polegać zmieniają się z wersji na wersję i prędzej czy później będziesz zmuszony albo do utrzymywania swojej własnej gałęzi, albo do przepisywania swoich modyfikacji w czasie zmiany wersji).

A gdyby core-team zdecydowal sie robic inclusion ( include_once() czy cos takiego ) jakiegos skryptu php w przypadku jego istnienia ? To chyba byloby najbardziej elastyczne i eleganckie rozwiazanie.

śmiało możesz założyć, że będziesz chciał upgrade'ować, ze względu na nowe funkcjonalności.

Ok.