wo Code ablegen für $syb = new DB_Sybase("hostname"

[knb]

Ich will eine Klasse schreiben mit der ich Modulprogrammierern die Möglichkeit geben will auf eine externe DB zuzugreifen.
Der Mechanismus soll ähnlich sein wie beim zugriff auf die mysql-Datenbank, nur statt

Code: Alles auswählen

$myb = new DB_Contenido;

soll man schreiben

Code: Alles auswählen

$syb= new DB_Sybase("hostname");

oder vielleicht

Code: Alles auswählen

$syb= new DB_Sybase("hostname", "dbname");

und dann mit den gleichen Methoden, iteratoren etc auf das Objekt zugreifen.

Meine Frage ist...wo lege ich am besten den PHP Code dafür ab?
Ich muss wohl eigene files erzeugen. Beim nächsten Release-Upgrade würden sie ja überschrieben werden.


Oder ist es überhaupt ratsam so vorzugehen? :


in includes/startup.php hinter

Code: Alles auswählen

checkMySQLConnectivity();

als letzte Zeile

Code: Alles auswählen

checkSybaseConnectivity();

hinzufügen

in startup.php weitere codezeile includen

neue Datei anlegen

functions.nobelpreisverdaechtig.php in

ja wo denn nur ?

in classes?
in conlib?
in tools ?
in contenido/includes?
in plugins?

welches Directory ist dafür am besten geeignet?

Gibt es eine empfohlene Namenskonvention?

Welche Dateien muss ich noch aufbohren ausser startup.php ?
In conlib/db_sybase.inc wollte ich die Klasse DB_sql einfach umbenennen.

Aber wo und wie sollte ich dann db_sybase.inc denn includen?

Ich weiss, die Klasse genericdb gibts ja auch noch aber diese Klasse dient einem anderen Zweck und überhaupt die zahlreichen Threads zu dem Thema kann ich kaum nachvollziehen.

[emergence]

also ich würde ein plugin daraus basteln...

ist unempfindlich gegen ein upgrade...
eine weitere datei musst du an sich nicht dafür aufboren...

[HerrB]

eine weitere datei musst du an sich nicht dafür aufboren...

Ähm, das würde mich jetzt intessieren ... sicher? In der genericdb ist die DB_Contenido fest verdrahtet...

Es ist relativ einfach, feste, weitere DB_x-Objekte zu erzeugen (conlib/local.php), aber um damit wie gewohnt auf (neue) Objekte zugreifen zu können, muss man IMHO die class.genericdb.php aufbohren, so dass man der (neuen) Klasse auch die DB-Instanz übergeben kann.

Funzt eigentlich sehr gut - man muss natürlich darauf achten, dass die Tabellen dem Contenido-Schema entsprechen (so im Großen und Ganzen). Und man benötigt in der zweiten DB eine xy_sequence, die die IDs verwaltet (man muss da noch was beim Namen beachten, fällt mir gerade nicht ein).

Das einzige, was ich noch nicht zum Laufen gebracht habe, ist die Verwendung der Properties (in der zweiten DBk, über set und getProperty), da hier ebenfalls die DB-Instanz übergeben werden müsste, was sich aber an der Stelle nicht so gut macht.

Es kann aber natürllich sein, dass ich da was übersehen habe, wie es einfacher geht ... da bin ich für jeden Tipp dankbar...

Meine "generische" class.genericdb.sql kann ich auf Anfrage gerne zur Verfügung stellen...

Gruß
HerrB

[emergence]

eine weitere datei musst du an sich nicht dafür aufboren...

Ähm, das würde mich jetzt intessieren ... sicher?

ja sicher...

solange man nur den zugriff auf eine andere db erreichen möchte reicht ein plugin vollkommen aus...

ein aufboren bringt es nur dann wenn man contenido komplett auf sybase umstellen möchte und gleichzeitig alle methoden der einzelnen klassen nutzen möchte... (da muss man auch die genericcb hacken)

in der conlib/prepend.php3 kann man für diesen fall einfach auf den sybase treiber (falls einer vorhanden ist) umstellen...
in wie weit die einzelnen sql queries die kreuz und quer über das system verteilt sind dann nutzbar sind, ist ne ganz andere sache...

aber so hab ich das posting auch nicht verstanden...

es soll nur eine weitere andere db zur normalen mysql db ansprechbar sein... und für das reicht ein plugin...

[HerrB]

Gut, aber das kann er damit nicht realisieren, oder?

und dann mit den gleichen Methoden, iteratoren etc auf das Objekt zugreifen.

Gruß
HerrB

[knb]

die contenido-db soll in mysql bleiben. Es liegen andere Daten in der externen DB, z.B. die Kontaktdaten der Frontend-User, auf die ich per modul zugreifen will.

Es ist halt unschön wenn man in einem Modul auf die contenido DB objektorientiert zugreift und auf externe DBs prozedural.

[HerrB]

Ich kann ja mal meine Lösung posten und emergence - bei Zeit und Lust - sagen, ob ich da Murx fabriziert habe. Kommt heute abend.

Gruß
HerrB