myGeeBlog

Prace nad Core osiągnęły pewien punkt zwrotny (w żadnym wypadku nie zostały przerwane, choć może cisza w repozytorium mogłaby to sugerować). Stwierdziliśmy z larkiem że trzeba przeorganizować i przepisać całe Core, aby móc je efektywnie rozwijać. Co też zaczeliśmy czynić. Przepisywanie zaczeliśmy od tego, od czego powinniśmy: od gadania :)

Postawiliśmy sobie prywatne wiki, gdzie spisujemy koncepcje i pomysły na to jak ma to działać i wyglądać. Zmieni się dosłownie wszystko - poza założeniami: ma być lekkie i szybkie. Będzie oczywiście miało dotychczasową funkcjonalność, będzie miało też obiecywaną dla wersji 0.5.0 funkcjonalność (galerie etc).

Zmieni się system szablonów (największe szanse w tej chwili ma system Open Power Template, w skrócie OPT). W tej kwestii jedno jest pewne: na pewno nie będzie to smarty, ponieważ obydwaj z larkiem posiadamy na smartowstręt :)

Zmienią się też wymagania systemowe (jak zresztą niketóre osoby, sprawdzające OPTy, mogły zauważyć) dla Core. Podstawą będzie: PHP 5.0 + PECLowe PDO lub też wersja PHP 5.1.x, gdzie PDO jest wbudowane.

Innym wymaganiem będzie wersja MySQL - od teraz wymagać będziemy wersji >= 4.1. Choć mam chrapkę na 5.0 ;) Widoki i triggery etc.. mniam… Niestety, o ile PHP 5.0.x jest coraz popularniejsze na komercyjnych serwerach, o tyle MySQL w tejże wersji niestety jest zbyt daleko w tyle. Szkoda.

Nie wiem na ile się uda, ale chciałbym móc puścić nowe Core na UTF-8 (to, jak dla mnie, jedna z ważniejszych przyczyn przejścia na MySQL 4.1.x, które intensywniej wspiera to kodowanie).

No i oczywiście korzystanie z PHP 5.x nie jest podyktowane tylko modą i PDO - które przecież też można mieć do wersji 4.x. Większym problemem jest tutaj duuuuża różnica w “obiektówce” tychże wersji PHP. W PHP 5.x model obiektowy został przepisany od nowa, zaimplementowany w zupełnie inny sposób, i chcielibyśmy skorzystać z jego dobrodziejstw. Co też zaczęliśmy już robić… :)

Jeszcze jednym powodem do przepisania całości jest to, że stara wersja, wraz ze starym systemem szablonów, kiepsko się nadaje do dodania obsługi pluginów do systemu. A w nowej będziemy starali sie to robić tak, żeby tą obsługę mozna było jak najszybciej dodać - umożliwi to niec łatwiejszy rozwój całości systemu.

Jednak mi się dziś chciało. Zrobiłem skrypta do konwersji całości Wordpressa z ISO-8859-2 na UTF-8. Oczywiście może też posłużyc do konwersji całkiem innych kodowań, wystarczy zmienić argumenty w wywołaniu funkcji iconv(). Skrypt znajduje się pod adresem: urzenia.net/wp-content/iso2utf/. Można go dowolnie zmieniać i wykorzystywać do własnych potrzeb, zgodnie z zasadami GPLv2.

Skrypt zmienia tylko zawartość bazy, te tabele i pola które uznałem że trzeba zmienić, reszta (przynajmniej w wersji WP 1.5.1.2 nie musi być konwertowana.

Skrypt nie zmienia za to collation w wersjach MySQL wyższych niż 4.0, więc do tego potrzeba ręcznie pogrzebać w bazie danych. Mi zajęło to jakieś 30 minut, ale nie chciałem tego robić automatem. Poza tym wszystko działa :)

Po zakończeniu działania skryptu, w katalogu w którym on się znajduje będzie utworzony plik converted.sql, który trzeba ręcznie wrzucić do bazy - również tego nie chciałem żeby robić automatem - nigdy nie miałem do nich zaufania ;)

Oczywiście nie biorę odpowiedzialności za złe działanie skryptu (za dobre zresztą też nie), etc etc. Używasz go na własną odpowiedzialność :)

Jeśli gdzieś ktoś dojrzy na diary jakieś problemy z pl-znaczkami, to proszę o info.

Tak, właśnie takie coś sobie wymyśliłem jak siedziałem wczoraj w sądzie więzieniu. Do dyspozycji miałem:

• tradycyjny interfejs proceduralny mysql_*
• nowy w php5 interfejs mysqli_ (proceduralny)
• j.w. mysqli, ale obiektowo (OOP)
• uniwersalny interfejs (w wersjach PHP < 5.1.0 dostępny poprzez PECL) PDO

Niestety, o ile w wersji Windows-owej w pracy miałem wersję PHP 5.1.0beta3 (z wbudowanym PDO), o tyle w domu i na serwerze na którym stoi urzenia jest starsze, stabilne PHP 5.0.5, na którym wersja PECL-owa PDO nie chce mi działać. Ale też jakoś specjalnie nie walczyłem, żeby zadziałało. Nie chce mi się :)

Wyniki, wraz z testami online, można obejrzeć pod urzenia.net/wp-content/mysql_test/, a żródła plików: urzenia.net/wp-content/mysql_test/sources/.

Dostępne tam są, na dole, 3 linki do wyników jakie uzyskałem na 3 kompach, na których chciało mi się bawić w testy. Najbardziej mnie zszokowało porównanie z P4 2.4 GHZ i AMD64… heheh. Nie ma to jak 64 bity :) Do każdego z linków jest którki opis, na jakim sprzęcie były wykonywane testy, jaki soft etc.

Moje podsumowanie: nie ma znaczenia, którego z interfejsów się użyje. Różnice w wydajności między nimi są tak niewielkie, że imo pomijalne. Dla mnie najwygodniejszy chwilowo się wydaje MySQLi, choć zdecydowanie PDO zasługuje na uwagę. Niestety, na tą chwilę PHP5 (nie mówiąc o wszechdostępności PDO, związanej z nieistnieniem wersji stabilnej/końcowej PHP5.1 i nie działaniem - u mnie - wersji PECL-owej) nie jest jeszcze tak rozpowszechnione jak bym chciał, ze względu na niekompatybilność części softu, dostosowanej do możliwości i błędów ;) starszej wersji, tj. PHP4. Choć w wolnych chwilach prawdopodobnie zacznę przerabiać Core CMS na ‘międzymordzie’ (interfejs) MySQLi… :)

Niedługo też zostaną wznowione prace nad telefonami, które też może doczekają się przejścia na MySQLi, jako że następny hosting będzie u providera, który oferuje PHP5 :) Które to PHP coraz bardziej podbija moje serce (w stosunku do PHP4, nie w ogólności, gdzie python króluje… :) ).

Wszelkie uwagi i ew. zgłoszenia błędów procedury testowej proszę zostawiać w komentarzach - postaram się nimi zająć tak szybko jak się da :)

banal. ale przy okazji wyszedl niezly bezsens…

# grep mysql /etc/tcpd/hosts.allow
mysqld: ALL: allow
# 

i smiga. ale czy rzeczywiscie brak wpisu (a w tym wypadku - niewlasciwy wpis) powinien powodowac segfault mysqla przy probie polaczenia ? dla mnie bzdura. niech nie pozwoli sie polaczyc, niech wywali jakis msg, ale kuzwa, nie segfault !!!

w sumie drugi raz sie przejechalem, ale nie do konca udalo mi sie wszystko powiazac…

pamietajac wlasnie ten poprzedni raz, oidp to bylo z serwerem jabbera, dodalem wpis do /etc/tcpd/hosts.allow:

mysql: ALL: allow

niestety, proces nazywa sie mysqld, a mi sie cos pozajaczkowalo. i tcpwrappers nie puszcal polaczen. ale kuzwa, dalej uwazam za maksymalna bzdure to, ze wali po oczach segfaultem zamiast zwyczajnie zabronic sie polaczyc. czy chocby siakis mesg… ech :/

dzieki ci, boze, za strace‘a… ;)

na serwerze jest sobie mysql 4.0.x. bodajze x = 24 obecnie (wczesniej bylo 20, ten sam problem), ale moge krzanic a sprawdzac mi sie nie chce. google niewiele sensownego mowia o moim problemie, wiec nieco szlag mnie trafia.
gdzie lezy problem?

musze uruchomic mysql tak, zeby mozna sie bylo zalogowac zdalnie do niego. no wiec zahaszowalem w konfigu skip-network.
ustawilem grzecznie odpowiednie bind-address. probowalem rowniez bez tego, ale nic to nie zmienia.

zrestartowalem mysql.

dodalem odpowiednie uprawnienia dla usera login@%.

zrobilem flush-privileges.

wszystko ladnie smiga, proba polaczenia z mysql z podanym parametrem -h:

% mysql -h adres -u user -p

po chwili mam mesga, ze polaczenie zerwane w trakcie wykonywania query czy jakos podobnie, po zalogowaniu na serwer (dobrze ze mam klucze, bo bez mysql na serwer normalnie nie da sie zalogowac…) service mysql status pokazuje ze nie dziala ale podsystem zablokowany (zginal tak szynko ze z /var/lock/subsys nie usunal locka).

w logach:

/usr/sbin/mysqld: gotowe do polaczenia PLD Linux Distribution MySQL RPM
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K
bytes of memory
Hope that’s ok; if not, decrease some variables in the equation.

moge sobie dowolnie mieszac zmiennymi, ilosc potrzebnej mu pamieci w msg spada do jakichs 60mb etc (chwilowo na serwerze zostalo tylko 512mb ramu, ale to przejsciowe), ale ten mesg sie dalej pokazuje wraz z wykladaniem sie mysql przy probioe polaczenia zdalnego.

proba polaczenia z serwera, ale z podanym parametrem -h adres powoduje dokladnie to samo. tylko dzialania na sockecie sa ok :/ nic nie czaje. no nic, moze zaraz na pisze na listy pld, moze cos pomoga (probowalem juz nawet mielic mysql samemu etc, i dalej to samo :///).

a tutaj mamy rozwiazanie problemu…

to tak w skrocie. od dwoch godzin walcze z prymitywem. po prostu kurwa z prymitywem. prosty skrypt w pythonie, wykonujace banalne kurwa query, wsadzajace do mysql jeden pojedynczy kurwa rekord. to samo query wykonane z poziomu phpmyadmina dziala. z konsolki mysqlowej - dziala. ale ze skryptu nie. czemu ? nie wiem. kurwa, jak bozie kocham, nie wiem. 25 innych skrypcikow, ktore rowniez wykonuja po jednym/dwa query, dziala jak trzeba. wszystko smiga. ale ten jeden nie chce. kurwa, niech chociaz wyswietli czemu nie chce! ale nie, po co. teoretycznie nie ma zadnego bledu!

zadnego!!! nie rzuca zadnym wyjatkiem, kod powrotu ze skryptu zerowy, wszystko wporzo. ale rekord w bazie sie nie pojawia.

ciekakurwawostka:

jest autoincrement id. id wynosi 114. po dodaniu tego wlasnie zapytania poprzez phpmyadmin. sprobuje to samo zrobic z poziomu skryptu: oczywiscie nie dziala, bo po co. ale teraz wykonuje jeszcze_raz to samo zapytanie z poziomu phpmyadmin, rekord oczywiscie sie pjawia… ale z id 116 ! kurwa… czary i magia. zaciagnelem najswiezsza wersje mysqldb, i wszystko co tylko moglo miec na to wplyw, i ni huhu nie dziala. wtf ?

dobra, madafaka. juz wiem mniej wiecej co jest grane. jebane mysqldb nie dziala z tabelami w innodb. aaaarrrghhh…. ciekawe co google mi na to powiedza…

hm, notki na stronie mysqldb twierdza, ze nie powinno byc problemow… jebukurwadu.

dymam to. jutro moze na news zajrze zobacze co mi powiedza…

update

doszedlem o co chodzi. innodb obsluguje transakcje, no wiec powinno to wygladac tak:

conn.BeginTrans()
conn.Execute(query)
conn.CommitTrans()

niestety, powyzszy kod wywala mi:

Traceback (most recent call last):
  File "./add_db_dns_record.py", line 40, in ?
    conn.BeginTrans()
  File "/usr/share/python2.4/site-packages/adodb_mysql.py", line 43, in BeginTrans
    self._conn.begin()
AttributeError: 'Connection' object has no attribute 'begin'

no i dupa blada. zglosilem bugreporta, zobaczymy czy i co mi napisza…