coś co można uznać na nową wersję LMS-a numerowaną jako 1.11.14
Witam,
Dziś oznaczyłem wersję z 24 kwietnia 2013 w github.com jako wersję 1.11.14: https://github.com/lmsgit/lms/tree/LMS_011114 Jako, że późniejsze zmiany w LMS są bardzo inwazyjne uznałem, że będzie najlepiej jak da się trochę odetchnąć użytkownikom LMS-a korzystając z tego w miarę stabilnej migawki. Jest to wyłącznie znacznik (tag) w repozytorium git, a bieżące poprawki będą nanoszone wyłącznie w bieżącej gałęzi master. Zapraszam to testów wersji bieżących z gałęzi master, a kto nie ma na to czasu, może pozostać przy wersji dzisiaj oznakowanej właśnie jako LMS_011114.
W dniu 07.05.2013 19:37, Tomasz Chiliński pisze:
Witam,
Dziś oznaczyłem wersję z 24 kwietnia 2013 w github.com jako wersję 1.11.14: https://github.com/lmsgit/lms/tree/LMS_011114 Jako, że późniejsze zmiany w LMS są bardzo inwazyjne uznałem, że będzie najlepiej jak da się trochę odetchnąć użytkownikom LMS-a korzystając z tego w miarę stabilnej migawki. Jest to wyłącznie znacznik (tag) w repozytorium git, a bieżące poprawki będą nanoszone wyłącznie w bieżącej gałęzi master. Zapraszam to testów wersji bieżących z gałęzi master, a kto nie ma na to czasu, może pozostać przy wersji dzisiaj oznakowanej właśnie jako LMS_011114.
Witam
LMS jest bardzo udanym projektem, świadczy o tym że na bazie tego projektu powstaje od groma klonów, jak również to, że większość małych ISP go używa a na bank próbowało.
Ja bym zasugerował zatrzymać się i przemyśleć kilka spraw:
- wprowadzenie MVC (http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) - porzucenie wsparcia dla MySQL - dystrybucja projektu również w formie wirtualnej maszyny
IMO im szybciej tym lepiej, a wy co byście uwzględnili w roadmap?
Pozdrawiam Serdecznie
W dniu 2013-05-08 10:52, Jarosław 'YArii' Kłopotek pisze:
Witam
Hej.
LMS jest bardzo udanym projektem, świadczy o tym że na bazie tego projektu powstaje od groma klonów, jak również to, że większość małych ISP go używa a na bank próbowało.
Ja bym zasugerował zatrzymać się i przemyśleć kilka spraw:
- wprowadzenie MVC
(http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller)
- porzucenie wsparcia dla MySQL
Dlaczego porzucenie mysql? Ja myślę, że najsensowniejsze byłoby ustalenie ile instalacji używa jakiego silnika baz danych i na podstawie tego eliminowanie. Bo faktycznie jeśli mysql używa tylko kilka procent instalacji to nie ma sensu dalej utrzymywać.
- dystrybucja projektu również w formie wirtualnej maszyny
IMO im szybciej tym lepiej, a wy co byście uwzględnili w roadmap?
Pozdrawiam Serdecznie
W dniu 08.05.2013 10:55, Waldemar Fraś napisał(a):
W dniu 2013-05-08 10:52, Jarosław 'YArii' Kłopotek pisze: Witam
Hej.
LMS jest bardzo udanym projektem, świadczy o tym że na bazie tego projektu powstaje od groma klonów, jak również to, że większość małych ISP go używa a na bank próbowało.
Ja bym zasugerował zatrzymać się i przemyśleć kilka spraw:
- wprowadzenie MVC
(http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller)
- porzucenie wsparcia dla MySQL
Dlaczego porzucenie mysql? Ja myślę, że najsensowniejsze byłoby ustalenie ile instalacji używa jakiego silnika baz danych i na podstawie tego eliminowanie. Bo faktycznie jeśli mysql używa tylko kilka procent instalacji to nie ma sensu dalej utrzymywać.
Może pod uwagę wziąć jaki system operacyjny najczęściej jest używany na którym ludzie przeglądają LMS.
- dystrybucja projektu również w formie wirtualnej maszyny
IMO im szybciej tym lepiej, a wy co byście uwzględnili w roadmap?
Pozdrawiam Serdecznie
W dniu 08.05.2013 10:55, Waldemar Fraś pisze:
- porzucenie wsparcia dla MySQL
Dlaczego porzucenie mysql? Ja myślę, że najsensowniejsze byłoby ustalenie ile instalacji używa jakiego silnika baz danych i na podstawie tego eliminowanie. Bo faktycznie jeśli mysql używa tylko kilka procent instalacji to nie ma sensu dalej utrzymywać.
Bardziej chodziło mi o wybranie jednego z dwóch silników tak by ograniczyć ilość pracy patrząc na projekt w dłuższej perspektywie czasu. Porównań w sieci jest dużo. W żadnym wypadku nie chciałem wywoływać świętej wojny MySQL vs PostgreSQL.
Jeżeli da się używać dwóch silników wprowadzając dodatkową warstwę abstrakcji to po prostu super.
W dniu 09.05.2013 12:11, Jarosław 'YArii' Kłopotek napisał(a):
W dniu 08.05.2013 10:55, Waldemar Fraś pisze:
- porzucenie wsparcia dla MySQL
Dlaczego porzucenie mysql? Ja myślę, że najsensowniejsze byłoby ustalenie ile instalacji używa jakiego silnika baz danych i na podstawie tego eliminowanie. Bo faktycznie jeśli mysql używa tylko kilka procent instalacji to nie ma sensu dalej utrzymywać.
Bardziej chodziło mi o wybranie jednego z dwóch silników tak by ograniczyć ilość pracy patrząc na projekt w dłuższej perspektywie czasu. Porównań w sieci jest dużo. W żadnym wypadku nie chciałem wywoływać świętej wojny MySQL vs PostgreSQL.
Jeżeli da się używać dwóch silników wprowadzając dodatkową warstwę abstrakcji to po prostu super.
No właśnie, po co komu wojna. Niech tylko może ktoś robi intensywne testy na MySQL i przesyła poprawki ;-)
W dniu 08.05.2013 10:52, Jarosław 'YArii' Kłopotek napisał(a):
W dniu 07.05.2013 19:37, Tomasz Chiliński pisze: Witam,
Dziś oznaczyłem wersję z 24 kwietnia 2013 w github.com jako wersję 1.11.14: https://github.com/lmsgit/lms/tree/LMS_011114 Jako, że późniejsze zmiany w LMS są bardzo inwazyjne uznałem, że będzie najlepiej jak da się trochę odetchnąć użytkownikom LMS-a korzystając z tego w miarę stabilnej migawki. Jest to wyłącznie znacznik (tag) w repozytorium git, a bieżące poprawki będą nanoszone wyłącznie w bieżącej gałęzi master. Zapraszam to testów wersji bieżących z gałęzi master, a kto nie ma na to czasu, może pozostać przy wersji dzisiaj oznakowanej właśnie jako LMS_011114. Witam
Witam,
LMS jest bardzo udanym projektem, świadczy o tym że na bazie tego projektu powstaje od groma klonów, jak również to, że większość małych ISP go używa a na bank próbowało.
Ja bym zasugerował zatrzymać się i przemyśleć kilka spraw:
- wprowadzenie MVC
(http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller)
- porzucenie wsparcia dla MySQL
- dystrybucja projektu również w formie wirtualnej maszyny
IMO im szybciej tym lepiej, a wy co byście uwzględnili w roadmap?
A co to jak za komuny piszesz per "Wy"? ;-) Nie ma czegoś takiego jak "Wy", gdyż w tej chwili praktycznie tylko ja na stałe jestem przy LMS. Więc i nie ma żadnych roadmap, bo gdybym miał tylko i wyłącznie LMS-em zajmować się to bym w wolontariacie pracował i nie miał na chleb.
Pozdrawiam Serdecznie
Jest na githubie taki klon https://github.com/kyob/ASPA który jest zbudowany na frameworku CodeIgniter. Jest to bardzo prosty framework, zapewnia MVC, warstwę abstrakcji dla bazy danych, obsługę MySQL, MSSQL, Postgres i innych - czyli nie trzeba porzucać wsparcia dla jakiegoś silnika. Co prawda samego forka jeszcze nie testowałem ;) ale zapowiada się dobrze.
Przejście na OOP na pewno ułatwiłoby pracę nad nowymi funkcjami, ale trzeba się liczyć z dużym nakładem pracy.
W dniu 8 maja 2013 10:52 użytkownik Jarosław 'YArii' Kłopotek < jkl@interduo.pl> napisał:
W dniu 07.05.2013 19:37, Tomasz Chiliński pisze:
Witam,
Dziś oznaczyłem wersję z 24 kwietnia 2013 w github.com jako wersję 1.11.14: https://github.com/lmsgit/lms/**tree/LMS_011114https://github.com/lmsgit/lms/tree/LMS_011114 Jako, że późniejsze zmiany w LMS są bardzo inwazyjne uznałem, że będzie najlepiej jak da się trochę odetchnąć użytkownikom LMS-a korzystając z tego w miarę stabilnej migawki. Jest to wyłącznie znacznik (tag) w repozytorium git, a bieżące poprawki będą nanoszone wyłącznie w bieżącej gałęzi master. Zapraszam to testów wersji bieżących z gałęzi master, a kto nie ma na to czasu, może pozostać przy wersji dzisiaj oznakowanej właśnie jako LMS_011114.
Witam
LMS jest bardzo udanym projektem, świadczy o tym że na bazie tego projektu powstaje od groma klonów, jak również to, że większość małych ISP go używa a na bank próbowało.
Ja bym zasugerował zatrzymać się i przemyśleć kilka spraw:
- wprowadzenie MVC (http://en.wikipedia.org/wiki/**
Model%E2%80%93view%E2%80%**93controllerhttp://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller )
- porzucenie wsparcia dla MySQL
- dystrybucja projektu również w formie wirtualnej maszyny
IMO im szybciej tym lepiej, a wy co byście uwzględnili w roadmap?
Pozdrawiam Serdecznie
-- Jarosław 'YArii' Kłopotek mob +48 607 893 111 INTERDUO Ł.Bujek, J.Kłopotek, J.Sowa s.c. ul. Lubelska 36B/40 21-100 Lubartów tel 81 477 54 54
______________________________**_________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/**mailman/listinfo/lmshttp://lists.lms.org.pl/mailman/listinfo/lms
W dniu 08.05.2013 11:01, Maciej Lew napisał(a):
Jest na githubie taki klon https://github.com/kyob/ASPA [6] który jest zbudowany na frameworku CodeIgniter. Jest to bardzo prosty framework, zapewnia MVC, warstwę abstrakcji dla bazy danych, obsługę MySQL, MSSQL, Postgres i innych - czyli nie trzeba porzucać wsparcia dla jakiegoś silnika. Co prawda samego forka jeszcze nie testowałem ;) ale zapowiada się dobrze.
No właśnie, a ja nigdy nie byłem przeciwnikiem nowinek, ale od dłuższego czasu jestem również realistą ;-) Ludzie zaangażowani w rozwój LMS-a pracują wolontariacie, a żyją z prac wykonywanych na boku. Nie ma czegoś takiego jak sztab ludzi, którzy siedzią i czekają na opinie użytkowników, żeby czym prędzej im dogodzić. Myślałem nad tym, żeby skomercjalizować totalnie projekt LMS wrzucając na stronę główną banery swojej firmy i odsyłacze do komercyjnego wsparcia, ale co by na to inni współtwórcy LMS powiedzieli? ;-) Wydzielenie mojej prywatniej gałęzi "enterprise" na początek będzie ciekawym eksperymentem i zobaczymy jak to się potoczy.
Moja wieloletnia praktyka w kontaktach ze wszelkiej maści społecznościami pokazuje, że zawsze jest grupa doradców i pomysłodawców, a nie ma realizatorów ;-)
W dniu 8 maja 2013 10:52 użytkownik Jarosław 'YArii' Kłopotek jkl@interduo.pl napisał:
- porzucenie wsparcia dla MySQL
powiedz, w czym MySQL jest gorszy od postgresa? bo ja osobiście już nie widzię plusów za posgresem. Kiedyś może tak, ale obecnie IMHO mysql wygrywa z posgresem, choćby nawet w łatwości zrobienia replikacji.
-- Pozdrawiam Marcin / nicraM
Dojedź do 10 000 klientów, używaj helpdesku, miej ponad 200 aktywnych taryf i rób zapytania z grupowaniem. Poczujesz różnicę.
W dniu 08.05.2013 12:02, Krzysztof Drewicz napisał(a):
Dojedź do 10 000 klientów, używaj helpdesku, miej ponad 200 aktywnych taryf i rób zapytania z grupowaniem. Poczujesz różnicę.
No właśnie. I do tego nie będziesz męki z udawaniem wykonania zapytań przez MySQL. A po latach wychodzą szopki jakie narobił wcześniej miły dla oka MySQL. To co niektórzy traktują jako zaletę MySQL, tj. pobłażliwość składniową analizatora zapytań SQL, jest w rzeczywistości jego bardzo dużą wadą.
Hunterze: Dzięki, dobrze, że nie zostawiłeś mnie samego "w walce z wiatrakami" :)
W dniu 8 maja 2013 13:20 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
W dniu 08.05.2013 12:02, Krzysztof Drewicz napisał(a):
Dojedź do 10 000 klientów, używaj helpdesku, miej ponad 200 aktywnych taryf i rób zapytania z grupowaniem. Poczujesz różnicę.
No właśnie. I do tego nie będziesz męki z udawaniem wykonania zapytań przez MySQL. A po latach wychodzą szopki jakie narobił wcześniej miły dla oka MySQL. To co niektórzy traktują jako zaletę MySQL, tj. pobłażliwość składniową analizatora zapytań SQL, jest w rzeczywistości jego bardzo dużą wadą.
Hunterze: Dzięki, dobrze, że nie zostawiłeś mnie samego "w walce z wiatrakami" :)
Ja obecnie używam mysql, ale nie widzę przeciwwskazań, byś pewnego dnia ogłosił, że od wersji X będziesz rozwijać tylko bazę w postgresie. Jeżeli będzie to z korzyścią dla rozwoju projektu to jest to dobry krok.
pozdrawiam Grzegorz Cichowski
W dniu 8 maja 2013 13:41 użytkownik GC gcichowski@gmail.com napisał:
Ja obecnie używam mysql, ale nie widzę przeciwwskazań, byś pewnego dnia ogłosił, że od wersji X będziesz rozwijać tylko bazę w postgresie. Jeżeli będzie to z korzyścią dla rozwoju projektu to jest to dobry krok.
osobiście też nie zamykam się na postgresa, ba, nawet jakiś czas temu chciałem emigrować do niego, ale brak możliwości replikacji master-master odwódł mnie od tego czynu. Poza tym przerzucanie danych, echo. No ale skoro ktoś w pewnym momencie zadecyduje mysql basta, to trzeba będzia albo to zaakceptować albo zmienić projekt :)
ps. na wirtualce spróbuje sobie poprzerzucać, ciekaw jestem rezultatów skoro tak bardzo zachwalacie silnik.
-- Pozdrawiam Marcin / nicraM
Ja jestem świeżo po przenosinach z MySQL na PostgreSQL - od jakiegoś miesiąca produkcyjnie. W większości przypadków dużego wzrostu wydajności nie zauważyłem, ale są też przypadki, np. lista sieci IP, która wczytuje się ~15 razy szybciej.
Replikacje master-master da się zrobić: http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pool... Osobiście testowałem tylko master-slave na slony, nieprodukcyjnie - działało.
© 2011
W dniu 8 maja 2013 13:49 użytkownik Marcin marcin@nicram.net napisał:
W dniu 8 maja 2013 13:41 użytkownik GC gcichowski@gmail.com napisał:
Ja obecnie używam mysql, ale nie widzę przeciwwskazań, byś pewnego dnia ogłosił, że od wersji X będziesz rozwijać tylko bazę w postgresie. Jeżeli będzie to z korzyścią dla rozwoju projektu to jest to dobry krok.
osobiście też nie zamykam się na postgresa, ba, nawet jakiś czas temu chciałem emigrować do niego, ale brak możliwości replikacji master-master odwódł mnie od tego czynu. Poza tym przerzucanie danych, echo. No ale skoro ktoś w pewnym momencie zadecyduje mysql basta, to trzeba będzia albo to zaakceptować albo zmienić projekt :)
ps. na wirtualce spróbuje sobie poprzerzucać, ciekaw jestem rezultatów skoro tak bardzo zachwalacie silnik.
-- Pozdrawiam Marcin / nicraM _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 8 maja 2013 14:18 użytkownik Skiba Marek skibamarek@gmail.com napisał:
Ja jestem świeżo po przenosinach z MySQL na PostgreSQL - od jakiegoś miesiąca produkcyjnie. W większości przypadków dużego wzrostu wydajności nie zauważyłem, ale są też przypadki, np. lista sieci IP, która wczytuje się ~15 razy szybciej.
w jaki sposób przenosiłeś dane? czy zrobiłeś zwykłego dumpa z insertami czy może jakmś "magicznym" narzędziem?
-- Pozdrawiam Marcin / nicraM
W dniu 8 maja 2013 14:21 użytkownik Marcin marcin@nicram.net napisał:
w jaki sposób przenosiłeś dane? czy zrobiłeś zwykłego dumpa z insertami czy może jakmś "magicznym" narzędziem?
Posłużyłem się tym https://github.com/philipsoutham/py-mysql2pgsql Tworzyło mi to plik sql, do którego dorzuciłem na końcu zapytania, które aktualizowały sekwencje migrowanych tabel i tyle.
W dniu 8 maja 2013 14:29 użytkownik Skiba Marek skibamarek@gmail.com napisał:
Posłużyłem się tym https://github.com/philipsoutham/py-mysql2pgsql
probuje sie do tego zabrać, ale za chorobe nie chce się to zaintalować :( może jakaś sugestia?
#v+ root@testsql:/usr/src/py-mysql2pgsql# python setup.py install running install Checking .pth file support in /usr/local/lib/python2.7/dist-packages/ /usr/bin/python -E -c pass TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files running bdist_egg running egg_info writing requirements to py_mysql2pgsql.egg-info/requires.txt writing py_mysql2pgsql.egg-info/PKG-INFO writing top-level names to py_mysql2pgsql.egg-info/top_level.txt writing dependency_links to py_mysql2pgsql.egg-info/dependency_links.txt reading manifest file 'py_mysql2pgsql.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' warning: no previously-included files matching '*.pyc' found under directory '*' warning: no previously-included files matching '*.pyo' found under directory '*' warning: no previously-included files matching '*.DS_Store' found under directory '*' warning: no previously-included files matching '*.coverage' found under directory '*' no previously-included directories found matching 'tests/reports' writing manifest file 'py_mysql2pgsql.egg-info/SOURCES.txt' installing library code to build/bdist.linux-i686/egg running install_lib running build_py creating build/bdist.linux-i686/egg creating build/bdist.linux-i686/egg/mysql2pgsql copying build/lib.linux-i686-2.7/mysql2pgsql/mysql2pgsql.py -> build/bdist.linux-i686/egg/mysql2pgsql copying build/lib.linux-i686-2.7/mysql2pgsql/__init__.py -> build/bdist.linux-i686/egg/mysql2pgsql creating build/bdist.linux-i686/egg/mysql2pgsql/lib copying build/lib.linux-i686-2.7/mysql2pgsql/lib/postgres_file_writer.py -> build/bdist.linux-i686/egg/mysql2pgsql/lib copying build/lib.linux-i686-2.7/mysql2pgsql/lib/config.py -> build/bdist.linux-i686/egg/mysql2pgsql/lib copying build/lib.linux-i686-2.7/mysql2pgsql/lib/converter.py -> build/bdist.linux-i686/egg/mysql2pgsql/lib copying build/lib.linux-i686-2.7/mysql2pgsql/lib/postgres_writer.py -> build/bdist.linux-i686/egg/mysql2pgsql/lib copying build/lib.linux-i686-2.7/mysql2pgsql/lib/mysql_reader.py -> build/bdist.linux-i686/egg/mysql2pgsql/lib copying build/lib.linux-i686-2.7/mysql2pgsql/lib/postgres_db_writer.py -> build/bdist.linux-i686/egg/mysql2pgsql/lib copying build/lib.linux-i686-2.7/mysql2pgsql/lib/errors.py -> build/bdist.linux-i686/egg/mysql2pgsql/lib copying build/lib.linux-i686-2.7/mysql2pgsql/lib/__init__.py -> build/bdist.linux-i686/egg/mysql2pgsql/lib byte-compiling build/bdist.linux-i686/egg/mysql2pgsql/mysql2pgsql.py to mysql2pgsql.pyc byte-compiling build/bdist.linux-i686/egg/mysql2pgsql/__init__.py to __init__.pyc byte-compiling build/bdist.linux-i686/egg/mysql2pgsql/lib/postgres_file_writer.py to postgres_file_writer.pyc byte-compiling build/bdist.linux-i686/egg/mysql2pgsql/lib/config.py to config.pyc byte-compiling build/bdist.linux-i686/egg/mysql2pgsql/lib/converter.py to converter.pyc byte-compiling build/bdist.linux-i686/egg/mysql2pgsql/lib/postgres_writer.py to postgres_writer.pyc byte-compiling build/bdist.linux-i686/egg/mysql2pgsql/lib/mysql_reader.py to mysql_reader.pyc byte-compiling build/bdist.linux-i686/egg/mysql2pgsql/lib/postgres_db_writer.py to postgres_db_writer.pyc byte-compiling build/bdist.linux-i686/egg/mysql2pgsql/lib/errors.py to errors.pyc byte-compiling build/bdist.linux-i686/egg/mysql2pgsql/lib/__init__.py to __init__.pyc creating build/bdist.linux-i686/egg/EGG-INFO installing scripts to build/bdist.linux-i686/egg/EGG-INFO/scripts running install_scripts running build_scripts creating build/bdist.linux-i686/egg/EGG-INFO/scripts copying build/scripts-2.7/py-mysql2pgsql -> build/bdist.linux-i686/egg/EGG-INFO/scripts changing mode of build/bdist.linux-i686/egg/EGG-INFO/scripts/py-mysql2pgsql to 755 copying py_mysql2pgsql.egg-info/PKG-INFO -> build/bdist.linux-i686/egg/EGG-INFO copying py_mysql2pgsql.egg-info/SOURCES.txt -> build/bdist.linux-i686/egg/EGG-INFO copying py_mysql2pgsql.egg-info/dependency_links.txt -> build/bdist.linux-i686/egg/EGG-INFO copying py_mysql2pgsql.egg-info/not-zip-safe -> build/bdist.linux-i686/egg/EGG-INFO copying py_mysql2pgsql.egg-info/requires.txt -> build/bdist.linux-i686/egg/EGG-INFO copying py_mysql2pgsql.egg-info/top_level.txt -> build/bdist.linux-i686/egg/EGG-INFO creating 'dist/py_mysql2pgsql-0.1.6-py2.7.egg' and adding 'build/bdist.linux-i686/egg' to it removing 'build/bdist.linux-i686/egg' (and everything under it) Processing py_mysql2pgsql-0.1.6-py2.7.egg removing '/usr/local/lib/python2.7/dist-packages/py_mysql2pgsql-0.1.6-py2.7.egg' (and everything under it) creating /usr/local/lib/python2.7/dist-packages/py_mysql2pgsql-0.1.6-py2.7.egg Extracting py_mysql2pgsql-0.1.6-py2.7.egg to /usr/local/lib/python2.7/dist-packages py-mysql2pgsql 0.1.6 is already the active version in easy-install.pth Installing py-mysql2pgsql script to /usr/local/bin
Installed /usr/local/lib/python2.7/dist-packages/py_mysql2pgsql-0.1.6-py2.7.egg Processing dependencies for py-mysql2pgsql==0.1.6 Searching for psycopg2>=2.4.2 Reading http://pypi.python.org/simple/psycopg2/ Reading http://initd.org/psycopg/ Reading http://initd.org/projects/psycopg2 Best match: psycopg2 2.5 Downloading http://pypi.python.org/packages/source/p/psycopg2/psycopg2-2.5.tar.gz#md5=fa... Processing psycopg2-2.5.tar.gz Writing /tmp/easy_install-RtoniR/psycopg2-2.5/setup.cfg Running psycopg2-2.5/setup.py -q bdist_egg --dist-dir /tmp/easy_install-RtoniR/psycopg2-2.5/egg-dist-tmp-pI8oUq warning: no files found matching '*.py' under directory 'ZPsycopgDA' warning: no files found matching '*.gif' under directory 'ZPsycopgDA' warning: no files found matching '*.dtml' under directory 'ZPsycopgDA' warning: no files found matching '*' under directory 'psycopg2da' warning: no files found matching '*' under directory 'debian' no previously-included directories found matching 'doc/src/_build' warning: no files found matching 'ChangeLog' In file included from psycopg/psycopgmodule.c:27:0: ./psycopg/psycopg.h:30:20: fatal error: Python.h: Nie ma takiego pliku ani katalogu compilation terminated. error: Setup script exited with error: command 'gcc' failed with exit status 1 root@testsql:/usr/src/py-mysql2pgsql# #v-
-- Pozdrawiam Marcin / nicraM
2013/5/17 Marcin marcin@nicram.net:
./psycopg/psycopg.h:30:20: fatal error: Python.h: Nie ma takiego pliku ani katalogu compilation terminated. error: Setup script exited with error: command 'gcc' failed with exit status 1
to odpowiem sobie sam :) python-dev
zabieram sie za migracje, narazie na wirtualce, zobacze jakie będą różnice a pozatym muszę "podszkolić" swoją administrację posgresem. nigdy go nie używałem.
-- Pozdrawiam Marcin / nicraM
Przenosiny były bezbolesne? Masz jakieś rady jak to dobrze zrobić?
a jak jest z posgresem w przypadku awarii zasilania? łatwo naprawic baze/tabele? no i druga kwestia, czy można w postgresie (bo nie moge tego namierzyć) trzymać użytkownikow i uprawnienia w bazie? bo z tego co widzę, to wszysko odbywa się na "lokalnych" userach.
-- Pozdrawiam Marcin / nicraM
W dniu 08.05.2013 17:45, Marcin napisał(a):
a jak jest z posgresem w przypadku awarii zasilania? łatwo naprawic baze/tabele?
Haaa z moich doświadczeń wynika, że w MySQL jest mniej odporny na zaniki zasilania. Potem trzeba robić REPAIR TABLE ręcznie.
no i druga kwestia, czy można w postgresie (bo nie moge tego namierzyć) trzymać użytkownikow i uprawnienia w bazie? bo z tego co widzę, to wszysko odbywa się na "lokalnych" userach.
To źle widzisz. PostgreSQL ma swój oddzielny system uprawnień. Oczywiście można w pewnym sensie mapować użytkowników systemowych na PostgreSQL.
Moim zdaniem jałową dyskusją jest rozstrząsanie co który silnik posiada, gdy jednocześnie z jednego z nich korzysta się w zakresie podstawowym. Istotne różnice pojawiają się jak zacznie się korzystać w danym z silników z bardziej zaawansowanych rzeczy. Takim przypadku ciężko nazwać, że MySQL posiada np. coś takiego jak wyzwalacze z prawdziwego zdarzenia. Swego czasu zrobiłem jedną funkcją w PostgreSQL logowanie zmian dowolnych pól w bazie danych z natychmiastowym zapisem zmian do oddzielnych tabel SQL.
Poza tym pamiętaj, że MySQL miał kiedyś ambicje bycia czymś w rodzaju SQLite, a potem stwierdzono, że można z niego zrobić silnik do wszystkiego, a PostgreSQL ma zupełnie inny rodowód.
-- Pozdrawiam Marcin / nicraM
W dniu 08.05.2013 18:06, Tomasz Chiliński napisał(a):
W dniu 08.05.2013 17:45, Marcin napisał(a): a jak jest z posgresem w przypadku awarii zasilania? łatwo naprawic baze/tabele?
Haaa z moich doświadczeń wynika, że w MySQL jest mniej odporny na zaniki zasilania. Potem trzeba robić REPAIR TABLE ręcznie.
no i druga kwestia, czy można w postgresie (bo nie moge tego namierzyć) trzymać użytkownikow i uprawnienia w bazie? bo z tego co widzę, to wszysko odbywa się na "lokalnych" userach.
To źle widzisz. PostgreSQL ma swój oddzielny system uprawnień. Oczywiście można w pewnym sensie mapować użytkowników systemowych na PostgreSQL.
Moim zdaniem jałową dyskusją jest rozstrząsanie co który silnik posiada, gdy jednocześnie z jednego z nich korzysta się w zakresie podstawowym. Istotne różnice pojawiają się jak zacznie się korzystać w danym z silników z bardziej zaawansowanych rzeczy. Takim przypadku ciężko nazwać, że MySQL posiada np. coś takiego jak wyzwalacze z prawdziwego zdarzenia. Swego czasu zrobiłem jedną funkcją w PostgreSQL logowanie zmian dowolnych pól w bazie danych z natychmiastowym zapisem zmian do oddzielnych tabel SQL.
Poza tym pamiętaj, że MySQL miał kiedyś ambicje bycia czymś w rodzaju SQLite, a potem stwierdzono, że można z niego zrobić silnik do wszystkiego, a PostgreSQL ma zupełnie inny rodowód.
Może ktoś zaproponuje jak to ładnie można zrobić w MySQL: http://lists.lms.org.pl/pipermail/lms/2013-March/026102.html To pytanie pozostało bez odzewu, więc wniosek z tego taki, że ludzie, którzy czytają listę mailingową to zupełni laicy jeśli chodzi o obsługę baz danych... Już wiele razy w historii aktualizacji schematu bazy danych MySQL okazywało się, że silnik udawał, że coś robi, a po cichu szykował sam na siebie (i chyba swojego użytkownika) stryczek.
W dniu 8 maja 2013 18:06 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
W dniu 08.05.2013 17:45, Marcin napisał(a):
a jak jest z posgresem w przypadku awarii zasilania? łatwo naprawic
baze/tabele?
Haaa z moich doświadczeń wynika, że w MySQL jest mniej odporny na zaniki zasilania. Potem trzeba robić REPAIR TABLE ręcznie.
Też miałem takie doświadczenia, na szczęście zwykłe REPAIR TABLE zawsze wystarczało, żeby można było podnieść tabele do żywych. Apropo extremalnych sytuacji, ostatnio czytałem o PITR (Point In Time Recovery) w PostgreSQL, ktoś używa? Czy robicie tylko pg_dump(all) i pg_restore?
W dniu 08.05.2013 18:36, Skiba Marek napisał(a):
W dniu 8 maja 2013 18:06 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
W dniu 08.05.2013 17:45, Marcin napisał(a):
a jak jest z posgresem w przypadku awarii zasilania? łatwo naprawic baze/tabele?
Haaa z moich doświadczeń wynika, że w MySQL jest mniej odporny na zaniki zasilania. Potem trzeba robić REPAIR TABLE ręcznie.
Też miałem takie doświadczenia, na szczęście zwykłe REPAIR TABLE zawsze wystarczało, żeby można było podnieść tabele do żywych. Apropo extremalnych sytuacji, ostatnio czytałem o PITR (Point In Time Recovery) w PostgreSQL, ktoś używa? Czy robicie tylko pg_dump(all) i pg_restore?
A i owszem używamy PITR. MySQL też chyba ma podobny mechanizm jak wykonywanie migawek bazy danych, żeby potem móc spójną bazę w postaci binarnej przerzucić do innej lokalizacji? PITR przydaje się również przy synchronizacji węzłów klastrze pgsql przy "powrocie" z jednego węzłów do pracy, a przed rozpoczęciem synchronizacji "na żywo" na nowo podłączonym węźle.
U mnie jeszcze było przejście na GITa z wersji 1.11.13, więc pracy trochę było, ale raczej bezboleśnie.
* przygotowanie serwera PostgreSQL - czyli wgranie najnowszego schematu + uprawnienia, * oczywiście backup starego LMSa i bazy MySQL, * do backupu wrzuciłem plik upgradedb.php wraz z folderem upgradedb (z GITa), zmieniłem dane do bazy w lms.ini i odpaliłem LMS z plików backupu, tak aby zaktualizował się schemat bazy MySQL. * odpaliłem wcześniej skonfigurowanego py-mysql2pgsql, który mi wyciągnął dane z powyższego backupu, który miał aktualny schemat bazy, i wypluł plik SQL z poleceniami COPY, bez schematów tylko dane. * lekka modyfikacja pliku wynikowego, jeśli mamy takie potrzeby * i później zwykły import do PostgreSQL: psql -f /plik.sql * całość miałem zautomatyzowane, bo dużo testowałem (co polecam), więc wszystko powyżej robiło mi się w jakieś 20min, * później już tylko zostało logować się na wszystkie serwery z LMS Daemon, czy inne i zmieniać dane do bazy * całość bezboleśnie bo w najgorszym przypadku, któryś LMS Daemon będzie miał przez moment nieaktualne dane * po migracji polecam monitorować połączenia do bazy MySQL, żeby się upewnić przed całkowitym wyłączeniem, czy nic już z niej nie korzysta, i tyle...
jeśli ktoś ma mało lokalnych zmian to nie powinno być większych problemów, u mnie niestety tak nie było, jak już przeniosłem całość na GITa i odpaliłem gitstats, to wyszło że dodałem: 244 commitów, w których dodałem 147202 linii, a dużo rzeczy nie przenosiłem bo nie były już używane. Powodzenia.
© 2011
W dniu 8 maja 2013 16:11 użytkownik Łukasz Kopiszka lukasz@alfa-system.plnapisał:
Przenosiny były bezbolesne? Masz jakieś rady jak to dobrze zrobić?
-- Pozdrawiam, Łukasz Kopiszka
______________________________**_________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/**mailman/listinfo/lmshttp://lists.lms.org.pl/mailman/listinfo/lms
uczestnicy (10)
-
GC -
Jarosław 'YArii' Kłopotek -
Krzysztof Drewicz -
Maciej Lew -
Marcin -
Skiba Marek -
Tomasz Chiliński -
Tomasz Chiliński -
Waldemar Fraś -
Łukasz Kopiszka