Test caching of MariaDB on Windows #16303
Conversation
While Chocolatey simplifies things, we cannot cache the installs, and as such need to download and setup over and over again. Particularly, the MySQL installation fails sometimes for nightly builds, so we're better off using a cache. We also switch to MariaDB, because the downloads are much smaller so we safe some storage space for other caches.
|
My original intention here was to completely drop the Chocolatey installation, because it appears to be slow (takes about 4-5 minutes) for every job run. I started with replacing MySQL with MariaDB, because the latter has a much smaller distribution (about 80MB vs. more than 200MB), and I'm pretty confident that it can be cached (although that obviously doesn't work yet). Still, downloading a zip and a couple of manual setup steps seem to be sufficient. Then I had a look at SQLServer, but it seems there is no way to do something similar. The offered SQLServer Express download has a size of 4.1MB, but that is almost certainly just an installer, which would download the real thing during installation. So I don't think this can be cached. I wonder if it makes sense to proceed. Apparently, the Chocolatey MySQL installation fails occassionally for the nightlies (@iluuu1994 likely has noticed), so maybe only replacing this step would make sense. However, the failing tests would need to be sorted out (should probably be done anyway). Regarding SQLServer: I'm not convinced that the cost of installation (may be around 3-4 minutes per job run) outweighs the benefits. After all, ext/odbc and ext/pdo_odbc are not the best suited extensions to access SQLServer databases (instead ext/sqlsrv or ext/pdo_sqlsrv should be used), and there are more lightweight and maybe even readily available alternatives (and we should probably test against different databases anyway). cc @NattyNarwhal, @SakiTakamachi Thoughts? |
Usually Microsoft has an offline installer link buried somewhere... except apparently, they bury it behind the SQL Server online installer nowadays? That's silly, but I think I at least managed to find the normal non-advanced SQL Server Express 2022 download without having to run it.
Not sure what the best database would be - they're either going to be already better served by built-in or popular third-party extensions (MySQL family/Pg/SQLite/SQL Server), or annoying and proprietary (i.e. SQL Server/Db2). Not to mention the tests assume SQL Server. I suppose we can just skip anything dialect specific, or have multiple dialect versions of the test when possible. Or perhaps test i.e. SQL Server on one platform, but a different database on anotherr. |
Thank you! However, this is still an installer, so the installation cannot reasonably be cached (registry entries, possibly some files outside of the installation folder, and maybe more).
Me neither. Just checked the odbc and pdo_odbc GH issues, and found tickets about MS Access, SybaseASE, IBM i filesystem (IFS) ?, System i Access ?, Oracle and 4 (!) about SQLServer.
This annoys me for a long time. I can understand that we focused on SQLServer when the purpose-built extensions were new, but they are stable for a long time.
Yes, why not. My main point here is that our Windows jobs are already slow (test execution deals with many small files, and Windows/NTFS isn't good at that), and we spend about 10% of that time to install SQLServer. |
I do know a bit about the IBM i ODBC driver side (that is, System i Access is one of the older names for that ODBC driver); ODBC is what IBM is currently recommending for Db2 on that platform. I'm assuming the ODBC use we're seeing for databases with special extensions is when you can't install the extensions or working around issues in the extension. Thinking about DB drivers to test against, I think the Access driver still comes with Windows, at least? I remember there's a few quirky ODBC drivers in there (like an Excel or CSV one), but they're implementing SQL themselves on a non-DB. Clearly people are using Access still, and it doesn't mean using any dependencies outside of Windows. |
Thanks for the explanation!
I'm not sure if it's installed by default, but we could check that, and install if necessary (probably much faster than installing SQLServer). However, MS Access (the Jet engine) is rather limited, and quite special. I've run the odbc test suite: Then looked at the first failing test, and needed to apply the following to make it pass: ext/odbc/tests/bug44618.phpt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ext/odbc/tests/bug44618.phpt b/ext/odbc/tests/bug44618.phpt
index 3ee2e61a63..a0838d6554 100644
--- a/ext/odbc/tests/bug44618.phpt
+++ b/ext/odbc/tests/bug44618.phpt
@@ -15,7 +15,7 @@
include __DIR__ . "/config.inc";
$conn = odbc_connect($dsn, $user, $pass, SQL_CUR_USE_ODBC);
-odbc_exec($conn, "CREATE TABLE bug44618(ID INT, real1 REAL, text1 TEXT)");
+odbc_exec($conn, "CREATE TABLE bug44618(ID INT, real1 REAL, text1 MEMO)");
odbc_exec($conn, "INSERT INTO bug44618 VALUES (1, 10.0199995, 'testing 1,2,3')");
$result = odbc_exec($conn, "SELECT * FROM bug44618");So adapting for MS Access might not be hard (at least for several of the tests), but how to detect which database/driver is used? Scanning the DSN might be an option, although somewhat error prone, and would not work for system/user/file DSN. |
|
I'm closing this in favor of #17570. |
No description provided.