mridoni / gixsql

GixSQL is an ESQL preprocessor and a series of runtime libraries to enable GnuCOBOL to access PostgreSQL, ODBC, MySQL, Oracle and SQLite databases.
GNU General Public License v3.0
13 stars 6 forks source link

Question: How well is SQLite tested, how well can it be used when previously targeting PostgreSQL? #145

Open GitMensch opened 1 year ago

GitMensch commented 1 year ago

These are two totally different questions, but I think it may be possible to answer them together.

To split the questions a bit more:

When previously targeting PostgreSQL:

And as a last question: Would it be reasonable to add a Berkeley DB interface using SQLite C API? I don't know if BDB 6 (last un-released version under Sleepycat, last release would be BDB 5) supports that, but it may be interesting in any case.

mridoni commented 1 year ago
  • Do the same tests that are run on PostgreSQL also run on SQLite - and pass?

Yes, all of them are run and pass, there a few minor differences for things that are not testable under SQLite (features not supported, etc.) but that's the gist. I am attaching a log of the test suite running with GitHub Actions (I tend to forget that these runs are not publicly visible).

12_Run test suite.txt

  • Side question: Wouldn't it be reasonable to have the testing via GH Actions also use SQLite? It seems that only PostgreSQL and MySQL are tested there.

The test action runs tests for MySQL. PostgreSQL, SQLite and unixODBC (using s PostgreSQL backend). Oracle is not tested on GitHub because there is not an easy way to bring up a container with a test instance of the DBMS. It can be done (and it will be in the future) but requires some effort.

  • Concerning testing: any progress in including the NIST sql testsuite?

Not so far, unfortunately it is a very busy period with my day-job.

When previously targeting PostgreSQL:

  • Are there any experiences with multi-user access? I've read that writes will queue up, but I'm not sure what this means in the end.

Not so far, but I guess it's mainly a problem in a multi-threading environment. With separate processes the usual rules regarding transactions should apply. or maybe I just didn't understand the question... :smile:

  • Would there be more than BLOB access that is expected to need to be changed in EXEC SQL?

Not a lot, but I need some time (currently I have little) to stop and plan ahead.

And as a last question: Would it be reasonable to add a Berkeley DB interface using SQLite C API? I don't know if BDB 6 (last un-released version under Sleepycat, last release would be BDB 5) supports that, but it may be interesting in any case.

From what I see, this is supported only on BDB 11g and later, even though it is really interesting (thanks, I didn't know about it). Despite not really being free-software-friendly this might be still useful for some scenarios (e.g. in-house applications).