Drupal 2 különböző adatbázisszerverrel PEAR használatával

cre képe

Sziasztok!

A Drupalt mysql adatbázissal használom, ebben az adatbázisban vannak a rendszerhez ill. a tartalmakhoz kapcsolódó adatok.
Van egy másik adatbázisunk is (sqlanywhere), az itt tárolt adatokra is szükségem lenne.

A database.inc db_set_active függvényével lehet adatbázisok között váltani.
A conf.php-ba a $db_url-ből a leírás alapján csináltam egy asszociatív tömböt.
A database.inc db_set_active függvényét átírtam, hogy ha 'sqlanywhere' paramétert kap, akkor a 'database.pear.inc'-et szúrja be. (Bár most látom, hogy van itt egy 'TODO: Allow more than one database API to be present.' Lehet, hogy ez még nincs támogatva.).

Mikor meghivom a db_set_active('sqlanywhere'); paranccsal az adatbázisváltást, akkor a következő hibaüzenetet kapom:

Fatal error: Cannot redeclare db_connect() (previously declared in /var/www/portal/includes/database.mysql.inc:23) in /var/www/portal/includes/database.pear.inc on line 14

Ezek szerint PEAR-en keresztül egyszerre csak egy adatbázisszervert használhatok, ugye, s írjak egy külön sqlanywhere-t kezelő osztályt?

chx képe

Megromlott a körte a sok állásban, a 4.6-ban ki is dobták a kamrából. Izé, a PEAR-t bátran elfelejtheted, nincs karban tartva.

0
0
cre képe

Azt most már én is látom a changelog-ból, hogy megváltoztatják az adatbáziskezelési részét (is):
- database backend:
* the PEAR database backend is no longer supported.

De a legfrissebb PEAR DB (1.6.8) adatai azt mutatják, hogy olyan sokat nem állt az:

Release date: 2004-10-04 17:56 UTC
Release state: stable

(Tudja valaki, hogy miért nem támogatják tovább a PEAR-t?
A drupal.org ma használhatatlan számomra - állandóan 'time out'-ot kapok.)

0
0
Hojtsy Gábor képe

A PEAR backenddel semmi gond nem volt. Egyszerűen hatékonyabban (értsd gyorsabban) működő Postgres motort sikerült írni a PEAR nélkül. Másrészt pedig így a Drupal Postgres alapú futattásához sem szükséges a PEAR, ami ingyenes vagy olcsó hosztoknál előnyös tulajdonság. Ezen kívül a Drupal fejlesztők különben is szeretik elkerülni a külső libektől való függőségeket...

Tehát feltehetően nem lenne kifejezetten nehéz szintre hozni a PEAR backendet, de mivel a Drupal fejlesztői között organikus okok miatt elsöprő többségben MySQL használók vannak, illetve rajtuk kívül számottevő mértékben csak Postgresql illesztéssel foglalkozó fejlesztő van, ezért nem érte meg a csoportnak fenntartani. Az SQL kódok mindenesetre eléggé hordozhatóan íródnak (legalábbis a coreban mindenképpen), úgyhogy nem lehet nagy gond másik motor illesztésekor. Károlynak is az SQLite sajátosságait kellett figyelnie, nem a Drupalban lévő SQL lekérdezések megfogalmazásával volt gondja, amikor az SQLitehoz illesztette a rendszert.

0
0
cre képe

... sajnos.
pl.: node.module, function node_access_where_sql ->
egy lekérdezésbe ilyet tesz bele 'AND 1', ezt pl. a Sybase nem szereti, de a PEAR-es ModifyQuery-be bele lehetett rakni ezeket a cseréket.

locale.inc, function _locale_admin_manage_screen()
$translation = db_fetch_object(db_query("SELECT COUNT(*) AS translation FROM {locales_target} WHERE locale = '%s' AND translation != ''", $key));
Ezt se szereti a Sybase, mert már a táblában van egy 'translation' nevű mező.
Na mindegy, úgyis MySql alatt fog futni a Drupal core, s Sybase csak kiegészítő lesz.

0
0
Hojtsy Gábor képe

Szerintem ezeket javítani kellene, nem tűnnek nagy kunsztnak. Az elsőnek fel sme kell bukkannia, a node_access_where_sql() azért volt úgy megcsinálva, mert mindig bekerült a kimenete az SQL-ekbe, de az új rewrite esetén már nem feltétlenül. Vagy rosszul gondolom?

A második meg simán megoldható, más néven kell használni.

0
0
chx képe

a datancenterre ahol a drupal szerver van, rájár a rúd. tegnap egy központi switch, ma egy központi router döglött meg.

0
0
Hojtsy Gábor képe

Mivel az adatbázis függvények nevei megegyeznek, ezért egyszerre több réteg nem lehet a memóriában. Kell egy olyan réteget csinálnod, ami mindig az aktuális motort használja, amit szeretnél. De ha csak elszigetelt adatelérésről van szó, és nem akarod teljesen az sqlanywhere-t is használni tárként, akkor valami egyszerűbb egyedi megoldást javasolnék...

0
0
chx képe

Aki megcsinálja a multi db handlert (csöppet sem lehetetlen) az a következő úton induljon el: a database.*.inc fájlokban a függvények nevébe bele kell tenni az adatbázishandler nevét és a db_set_active -nak be kell állítani az aktuális adatbázishandler nevét. Végül kell írni 14 wrapper függvényt. Pl. a db_query meghívná a db_$handler_query -t call_user_func_array segítségével.

Aki belevág, az szerintem a HEAD-et reszelje. Bár abból kivette Dries a PEAR részleget, tehát azt elő kell szedni az Atticból és szintre hozni. Nagyon kérem azt, aki megcsinálja, hogy addja közre!

Csak jelzem, imádok Drupal database layert reszelni (szerényen szólva: értek is hozzá), tehát egészen baráti díjért megcsinálom :)

0
0
cre képe

Aki szintén belevágna, annak idemásolok 2 linket:

http://drupal.org/node/7461
http://drupal.org/node/13115

A második link akkor is érdekes, ha a két adatbázisszerver nem különbözik egymástól, csak az adatbázis. Ott a megvalósítás is le van írva.

0
0