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?
Megromlott a körte a sok ál
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.
4 hónap
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.)
Nem a PEAR-el van a gond
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.
A core-ban is van nem hordozható...
... 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.
ezeket javítani kellene
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.
drupal.org
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.
Egyszerre nem megy
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...
multi db handler készítése
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 :)
figyelni a watchdog-ra
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.