Seite 5 von 6

Re: Firebird + php 7: Bug im connect

Verfasst: Do 18. Apr 2019, 01:27
von vr2
Hallo ihr 2,

@Martin: Wenn wir schon in der main distribution mit ext-interbase nicht mehr enthalten sind, dann können wir dort auch aufhören, wie seit fast 20 Jahren unter dem Namen Interbase zu segeln. Gerade bei Firebird 3 und 4 sind reihenweise Features drin, die es bei Interbase nicht gibt. In der PHP-Mailingliste deutete einer zwar an, dass wir später nicht mehr in die main distribution reinkommen, wenn wir jetzt einen Firebird-Only-Treiber machen, aber das will ich erst mal sehen, bzw ist auch egal. Das hätten sie sich vorher überlegen können, dass wir dann nicht mehr an ihre Wünsche/Vorgaben gebunden sind, wenn sie uns rauswerfen. In Kürze gibt es dann nämlich keinen interbase-Treiber mehr, da Embarcadero sich mW überhaupt nicht drum kümmert. Die Umbenennung sollte kein Problem sein, es gab vor Jahren schon mal Vorschläge im PHP-Umfeld, den ext-interbase auch unter ext-firebird anzubieten bzw die Funktionen auch. Finde das natürlich nicht mehr.

@bfuerchau: Der Imageverlust setzt sich so zusammen: Bisher hat das PHP-Team signalisiert, dass sie die ext-interbase für so wichtig und qualitativ gut genug einstuften, dass sie die in der main distribution mit verwalteten und auslieferten. Das war ein Qualitätssiegel und wird gerade revidiert.

Auch wenn Du zufrieden mit .Net bist, finde ich es keine gute Idee, etwas so low-level wie einen Datenbanktreiber in Zwiebelschichten zu verpacken, auch die Verwendung von COM-Objekten macht die Sache nur komplexer. PHP implementert in C, soweit ich weiß, evtl C++, Geschmackssache, jedenfalls ist das die Ausgangsbasis. Wenn man 10 Mio Sätze irgendwo rausholen muss oder parallel mit zig Connections oder Transaktionen auf der DB rumorgelt, will man keinen Wrapper irgendwo.

Mit dem ODBC-Treiber hat das alles gar nichts zu tun, das war sicher ein Missverständnis.

Bzgl neue und akzeptierte Treiber: Auch pdo-Firebird, der von Dir und den PHP-Leuten wiederholt als Alternative ins Spiel gebracht wird, ist keine. Es gibt keinen Ersatz für einen native Treiber, es sei denn, man braucht nur eine Teilmenge der Features. Man kann dort keine Einschränkung auf den kleinsten gemeinsamen Nenner hinnehmen, die dadurch entsteht, dass ein API mehrere Datenbanksysteme abdecken soll. Das ist gerade der Sinn von native Treibern, dass sie den vollen Funktionsumfang eines DBMS zugänglich machen, ohne Rücksicht darauf, ob es das Feature in anderen Systemen auch gibt. Ein schönes Beispiel findet sich im native Firebird-Treiber für Python. Firebird unterstützt im Gegensatz zu einigen anderen DBs mehrfache unabhängige Transaktionen pro Connection: https://fdb.readthedocs.io/en/v2.0/usag ... ansactions. Die Designer des Python DB-APIs kannten dieses Konzept offensichtlich nicht. Entsprechend musste der Entwickler des native Firebird-Treibers an einigen Stellen mit workarounds arbeiten bzw die Vorgaben des APIs sogar verletzen. Sowas nervt bei einem native Treiber einfach nur. Einige Anwender brauchen den Werkzeugkasten 100% und den soll es genau so geben. Mit der Zeit finden sich dann mehr Leute, die den Nutzen erkennen. Aber dafür muss er überhaupt mal angeboten werden, und eben nicht "wir wissen schon, was gut für euch ist, den Rest braucht ihr eh nicht". Speziell, wenn das von Leuten kommt, die keine Datenbankprofis sind und obendrein von der konkreten Datenbank keine Ahnung haben.

Auf der PHP-pdo-Seite https://www.php.net/manual/de/book.pdo.php ist mit 100 "likes" der mit Abstand am höchsten bewertete Userkommentar
Won't work:
$sth = $dbh->prepare('SELECT name, colour, calories FROM ? WHERE calories < ?');
Natürlich nicht. Wie soll die DB ein prepare machen, wenn die Tabelle unbekannt ist?

Viele Kern-Entwickler der Web- und Skriptsprachenszene haben nach wie vor so gut wie keine Ahnung von Datenbanken. Entsprechend nutzen die meisten ihrer Anwender daher Datenbanken auf MySQL-Niveau und haben am liebsten gar nichts direkt mit der Datenbank zu tun, sind schon froh, wenn sie insert, update und delete hinbekommen. Von window functions haben die noch nie gehört, gibts bei MySQL auch nicht, oder lass die mal gezielt einen Index setzen, weil eine Abfrage lahmt. Aus der Ausgangssituation ergaben sich dann so krude, aber etablierte Konzepte wie MVC und ORM, die helfen, wenn man keine Ahnung von Datenbanken hat, auch nichts damit zu tun haben will, sie aber dynamisch nutzen muss. Wasch mir den Pelz, aber mach mich nicht nass. Ich halte das für eine Fehlentwicklung. Die Power und Eleganz, die man bekommt, wenn man die volle Leistungsfähigkeit eines DBMS wie Firebird nutzen kann und SQL die erste Fremdsprache ist, ist in einer anderen Liga. Ich habe das zu oft gesehen, in Shopsystemen, in CMS, in CRM-Systemen wie OroCRM/Symfony, das ist überall der selbe Käse.

Grüße, Volker

Re: Firebird + php 7: Bug im connect

Verfasst: Do 18. Apr 2019, 16:00
von bfuerchau
Da kann ich nur ausnamslos und vollkommen zustimmen. :!: :!: :!:
Ich hatte mir die PDO-Seite auch mal genauer angesehen und auch tatsächlich nichts nennenswertes bzgl. des Treibers gefunden, den Hinweis darauf ziehe ich hiermit zurück (wer weiß obs einer merkt ;) ). Auch die COM-Integration erscheint mir zugegeben, sehr schwerfällig von der nativen .Net-Integration ganz zu schweigen (oder hat da schon einer 4.0ff integriert?).

Da ich kein PHP programmiere kann ich den Stellenwert einiger Features nicht bewerten. Mein ODBC-Hinweis hat natürlich nichts mit PHP zu tun sondern diente halt nur zum Vergleich, dass .Net bereits erheblich mehr kann als ODBC und eben die Client-lib nicht mehr benötigt wird.

Nun brauch man sicherlich im 1. Schritt nicht alles, da aber der .Net-Treiber in C# entwickelt ist und Aufrufe zwischen .Net und anderen DLL's durchaus möglich und zuässig sind, könnte ich mir ebenso eine Integration des .Net-Treibers als Extension für PHP vorstellen.
Leider lässt es meine Zeit nicht zu, ein solches Projekt in Angriff zu nehmen, zumal da auch meine PHP-Kenntnisse nicht viel mehr umfassen als dessen Existenz, aber mit meinem Wissen zu unterstützen wäre ich gerne bereit dazu.

Und was die geschachtelten Transaktionen angeht, so habe ich diese bisher immer über "execute block" einbetten können und auch bei komplexen Operationen eigentlich noch nie gebraucht (bis auf wirklich wenige Ausnahmen wie temporäre DDL). Aber ich denke, auch sowas ließe sich durchaus auf Treiberebene realisieren (Transaktion-Stack).

Also wäre mal eher der .Net-Entwickler des Treibers zu befragen ob dessen Interesse an einer PHP-Integration geweckt werden könnte da nur ein natives C->.Net-Interface zu definieren wäre.
Zusätzlich könnte man eben die große PHP-Community eben für eine alternative, commerziell ebenso, kostenlose Datenbank begeistern, wenn sie wieder so einfach wie MySQL o.ä. integriert ist.

Das würde auch der Firebird-Community helfen.

Ich selber arbeite im BI-Umfeld seit FB 1.5, aktuell auf 2.5.7 und kann deine Aussagen bzgl. Funktionalität, Verwaltbarkeit (was ist das überhaupt), Stabilität und letztlich Performance nur bestätigen.
Einer meiner Geschäftskontakte stellt nun ebenfalls intensiv seine Anwendung komplett von SQL-Server auf Firebird um (wegen der enorm gestiegenen Lizenzkosten) und hat, dank meiner bescheidenen konzeptionellen Hilfe, Leistungssteigerungen z.T. bis unwahrscheinlichem Faktor 1000 festgestellt.

Und mach MVC und ORM nicht schlechter als sie sind, da man auf tiefer Ebene immer noch auf die SQL's Einfluss nehmen kann.

Re: Firebird + php 7: Bug im connect

Verfasst: Mi 24. Apr 2019, 08:18
von martin.koeditz
Guten Morgen Volker,

hier noch die 64-Bit-Version der Erweiterung als Thread Safe und Non-Thread Safe.

Gruß
Martin

Re: Firebird + php 7: Bug im connect

Verfasst: Do 9. Mai 2019, 22:09
von vr2
Hallo Martin,

vielen Dank, habe mir den 64-Bit-Treiber geholt - war im Urlaub, deshalb erst jetzt. Für welche php-Versionen ist der? Den 32er hab ich auch in 7.3.2er Apaches im Einsatz.

Gibts schon was Neues aus der php-Ecke? PECL, Dokuzugang für Dich usw?

Was hältst Du davon, den mal dem Firebird-Projekt zu geben, damit die ihn zum Download anbieten können? Damit wäre das Testfeld größer. Ich habe bisher keinerlei Probleme feststellen können, der Treiber ist in einigen Installationen unter Produktionsbedingungen seit 6 Wochen permanent im Einsatz.

Grüße Volker

Re: Firebird + php 7: Bug im connect

Verfasst: Fr 10. Mai 2019, 08:56
von martin.koeditz
Hi Volker,

der Urlaub sei dir gegönnt. Die 64-Bit-Treiber haben den gleichen Stand wie die 32er Pendants. Ich meine das sind 7.3.0.

Für den ibase-Treiber gibt es mittlerweile einen eigenen Bereich im PECL: https://pecl.php.net/package/interbase
Ich habe Kalle nochmals angeschrieben, da ich dort noch immer nicht als Maintainer eingeschrieben bin. Bislang ohne Rückmeldung.

Auch eine gute Idee. Wir sollten die Treiber vielleicht grundsätzlich über die Firebird-Homepage anbieten. Ich muss mir dann etwas bzgl. der Kompilierung überlegen. Wir brauchen dann ja mehrere Systeme im Einsatz (Win 32, 64 + Linux 32, 64). Mit Mac kann ich nicht dienen. Aber dafür finden wir dann sicherlich auch eine Lösung.

Gruß
Martin

Re: Firebird + php 7: Bug im connect

Verfasst: Di 11. Jun 2019, 22:25
von vr2
Hi Martin,
martin.koeditz hat geschrieben: Fr 10. Mai 2019, 08:56 Für den ibase-Treiber gibt es mittlerweile einen eigenen Bereich im PECL: https://pecl.php.net/package/interbase
Ich habe Kalle nochmals angeschrieben, da ich dort noch immer nicht als Maintainer eingeschrieben bin. Bislang ohne Rückmeldung.
Da ist Kalle selber als Maintainer eingetragen ;-)
Auch eine gute Idee. Wir sollten die Treiber vielleicht grundsätzlich über die Firebird-Homepage anbieten.
Ja, was sollen wir warten, bis sich bei PHP was tut, Firebird-Leute schauen ohnehin eher bei Firebird rein. Hab gesehen, es gibt auf http://www.firebirdsql.org/en/devel-php-driver/ nun auch die Linux-Version, super!

Übrigens hab ich evtl einen Bug in dem Treiber gefunden, in ibase_commit(): Ich habe ein php-Skript, das ein explizites commit machen muss, damit die nachfolgende Aktion die vorher inserteten Daten sieht. Mit dem Aufruf von ibase_commit() in seiner früher üblichen Form, also ohne Angabe eines DB- oder TX-Links, verendet ibase_commit sang- und klanglos. Es gibt nix im php-errorlog und keine Fehlermeldung. Es war mir auch nicht möglich, das zu debuggen, zb durch Klammern mit try/catch und Ausgabe der ibase-errmsg o.ä. Der hört da einfach auf und das Skript auch.

Rufe ich das ibase_commit mit gültigem DB-Link auf, also zB ibase_commit($usrDB), klappt alles wie erwartet. Gemäß Doku https://www.php.net/manual/de/function.ibase-commit.php müsste man ibase_commit aber auch ohne Link aufrufen können, der holt sich dann den aktiven DB-Link. Oder die Doku ist veraltet. Dann sollte aber eine Fehlermeldung kommen (not a valid database/tx resource oder so), wenn man ibase_commit so aufruft, ähnlich wie bei ibase_connect.

Kannst Du das bitte mal checken? Ich glaube, ich brauche keinen Testcase dafür zu bauen, der Fehler müsste grundsätzlich auftreten. Einfach von php aus irgendeine Aktion auf einer DB ausführen und dann ibase_commit() ohne Parameter aufrufen. Dahinter eine Logausgabe in eine Datei. Da kommt er nicht mehr hin.

Grüße, Volker

Re: Firebird + php 7: Bug im connect

Verfasst: Mi 12. Jun 2019, 10:40
von bfuerchau
Ist nicht einfach logisch, da man mehrere Connections geöffnet haben kann, einfach zwingend die Connection beim Commit/Rollback anzugeben?
Wenn du doch weißt, dass das Script dann abstürzt, gib die Verbindung halt an.

Bei JavaScript gibt es z.T. ähnliche Situationen, da die Aufrufparameter einer Funktion nicht typisiert sind und man eben erforderliche Parameter auch einfach weglassen kann.
Das führt dann u.a. auch zu Fehlern auf der ASP-Seite ohne irgendwelche Error/Logging-Hinweise.

Re: Firebird + php 7: Bug im connect

Verfasst: Mi 12. Jun 2019, 17:29
von vr2
Hi,
bfuerchau hat geschrieben: Mi 12. Jun 2019, 10:40 Ist nicht einfach logisch, da man mehrere Connections geöffnet haben kann, einfach zwingend die Connection beim Commit/Rollback anzugeben?
Wenn du doch weißt, dass das Script dann abstürzt, gib die Verbindung halt an.
Mach ich ja auch, nur darf eine API-Funktion, egal, ob die Doku falsch ist, nicht einfach so verenden. Die muss schon robust rauskommen, wenn ihr was fehlt, eine Exception auslösen, aber nicht das ganze Skript in den Abgrund reißen. Und laut Doku kann sie auch ohne Parameter aufgerufen werden.

DB-Funktionen verpflichtend mit Link aufzurufen war ja gerade eine der Neuerungen von php7, vorher wurde sich der DB-Link aus dem Laufzeitkontext zusammengereimt. Das geht jetzt nicht mehr und betrifft auch das commit. Insofern ist da vermutlich einfach noch was nicht umgestellt - schätze, der greift ins Leere und geht baden. Das ist für die Aktualisierung des php7-Treibers von Bedeutung.

Grüße, Volker

Re: Firebird + php 7: Bug im connect

Verfasst: Do 20. Jun 2019, 19:12
von martin.koeditz
Hallo Volker,

da gebe ich dir recht. Ich habe die PHP-Doku erweitert. Im Treiber waren noch etliche undokumentierte Funktionen. Darunter fielen auch die fbird-Funktionen, die ja bereits angedacht waren. Dabei bin ich auch über den angesprochenen Fehler gestolplert.

Nun gibt es die Mögleichkeit die Doku anzupassen oder das Verhalten an die Doku. Ich kann jedoch nicht sagen, was korrekt ist. Aus dem Bauch heraus würde ich sagen, das die Connection anzugeben ist, so wie bfuerchau bereits geschrieben hat.

Gruß
Martin

Re: Firebird + php 7: Bug im connect

Verfasst: Fr 2. Aug 2019, 16:24
von Hamburgo
Hallo zusammen,

heute habe ich es endlich hinbekommen, ein PHP 7.3.5 (64 Bit) mit FireBird 3.04.33054 FireBird 3.0 (64 Bit)
aufzusetzen.

Nun macht der Connect Probleme: Mein String

Code: $DbC = fbird_connect($Db['File'], $Db['Username'], $Db['Password']);

Klartext: $DbC = fbird_connect(//localhost/E:/DataBase/TDL/TDL-WWS.FDB, Username, Password);

Fehler-Meldung:
fbird_connect(): Install incomplete, please read the Compatibility chapter in the release notes for this version in P:\HTTP\INCLUDES\DataBaseConnect.php on line 61

Unter PHP 5.5.15 (32 Bit) mit FireBird 2.5.2.26540 FireBird 2.5 (32 Bit) klappt das wunderbar.

Hat das was mit dem Thema dieses Treads zu tun ?

Was habe ich zu korrigieren ?

Danke und viele Grüße
Bernd