Re: [RFC VOTE] Unbundle ext/interbase

Hi Kalle, On 02.05.2019 at 15:35, Kalle Sommer Nielsen wrote: > Den tor. 2. maj 2019 kl. 14.56 skrev Christoph M. Becker <cmbecker69@gmx..de>: >> A problem is that the ext/pdo_firebird tests rely on ext/interbase to >> create a test database[1], which would require everybody who intends to >> run these tests to install PECL/interbase package now. It would be >> great if somebody would rewrite this, so interbase would no longer be a >> dependency of the pdo_firebird tests. >> >> [1] >> <https://github.com/php/php-src/blob/PHP-7.4/ext/pdo_firebird/tests >> /testdb.inc> > > Yeah that is one thing that is kind of unfortunate and a bad practice. > However since interbase was disabled for AppVeyor, these tests had no > chance to run in a while. Looking at the actual code in testdb.inc, it > seems like it creates the database for testing purposes, I would > suppose this is due to PDO_Firebird perhaps requiring a database to > continue its connection flow in PDO itself. Indeed, it seems that pdo_firebird requires to connect to an existing database, contrary to e.g. pdo_mysql which supports DSN like mysql:host=localhost, to my knowledge. But even if pdo_firebird has been connected to an existing database, it appears that it's not possible to create a new database via PDO (I got something like "prepare does not support CREATE DATABASE", even with emulated prepares turned on). > I'm not sure how we can go about this, maybe a .sql file for testers > who run the test suite for schemas and then see if we can integrate > some auto importer in our CI build scripts for this special case? (In > the case we cannot go around PDO). Either way the test files requires > a manual touch to configure credentials to run. > > I'm personally fine with the simple solution, thoughts? ACK. Given that these test did not run on our CI (pdo_firebird is not even built on Travis) anyway, I think a simple solution which allows someone who wants to run the tests after some manual setup is sufficient as a first step. We always could improve on that later. > (ps. Thanks for the fix for the AppVeyor part I missed) No problemo! :) -- Christoph M. Becker