skrylar / firebird Goto Github PK

Firebird, as part of its support for Delphi inherited from Interbase most likely, allows Pascal strings. We should see if it is safe to hand Nim strings along using this interface, and avoid any copying created from the use of cstrings.

Example code to show how to use the library, which also need to be integrated with the docs. Lastly the examples allow us to see any pain points that could use some extra help (via templates) to make things easier.

We need to accept a string, write the length (in Firebird varchar format) to a buffer and blit the input string to the same buffer.

Under Arch, with Firebird 2.5, it is found in /usr/include. According to #1 it is not always found there, and I am uncertain if there is a pkg-config file we can use to find it.

Since Nim has named imports, you can just import firebird3 as isc if you want isc.dosomething everywhere. The ISC prefix should then be removed from type names, procs, and the documentation.

Tempted to say no on this one, because I don't really want to port all the docs over.
Texinfo

• Multiple indices (function index, concept index.)
• Includes the index with outputs by default.
• Can paginate without a Docbook/XSLT stack.
• Has rather ugly output; have to dig around with command line and template files to get a custom theme going.
• Everyone seems to hate writing it (didn't find it too troubling)

Asciidoc[tor.rb]

• Has pretty output by default
• But doesn't support multiple indexes (ex. no function index.)
• Requires a docbook/xslt stack to paginate.
• Requires the docbook/xslt stack to generate the ONE INDEX that it supports but won't actually do by itself.

Should be safe to do. It appears these exist to compensate for a lack of stdint.h and thus are not likely to change.

Either MIT or Interbase's own public license, depending on what the terms are. Documentation will probably go under the GNU FDL (again, depending on terms.)

Great effort to wrap the fbclient

Tried to compile with nim c ex01.nim on linux.
ibase.h was not picked up initially but was ok when I gave it the full path
#{.passl: "-lfbembed".} failed , after commenting out I get this:

/data5/NimTests/firebird/examples/nimcache/ex01.o: In function `NimMainModule':
ex01.c:(.text+0x168): undefined reference to `isc_dsql_execute_immediate'
ex01.c:(.text+0x18e): undefined reference to `isc_commit_transaction'
ex01.c:(.text+0x19d): undefined reference to `isc_detach_database'
collect2: error: ld returned 1 exit status

In firebird3 there is no libfbembed.so , I think embedded connections are via libEngine12.so
which is set in the configuration files.

In case you continue this effort it might be best to connect with the firebird developers
at https://www.firebirdsql.org via their developers mailing-list.

I am sure they are able and happy to answer any current and upcoming questions.

Maybe some of these manuals will help too: https://www.firebirdsql.org/en/reference-manuals/

My current solution https://github.com/qqtop/NimFirebird is via the python driver , but in the long run a "pure" nim driver is the way to go.

The firebird community is actually quite large and active in Brasil,Russia,Germany and Czech.

Under 2.5, there is fbembed. Under 3.0, that doesn't exist. Installing the dev, common and client packages under Deb/Sid results in non-working examples (they "cannot connect to localhost.")

Trying to find docs to force embedded mode (if possible,) although its proving difficult.

Reading from and writing to XSQLVAR is tedious, mostly due to historical C concerns. A handful of templates should make this relatively painless.

Should the wrapper check return codes from functions, and convert those in to exceptions?

A secondary question: should exceptions be generic, shallow tiered, or complex? Generic errors are the easiest and if using exceptions I would probably go this route. That would mean just checking that status is not zero, asking firebird to describe it (they have an example for this) and boxing that up in a simple exception that gets thrown. I'm not aware of a case where status codes represent some kind of "caution but not fatal" scenario.

A tiered approach fits Nim more closely, but starts requiring diving in to the error code header (it's quite huge) and trying to map those error codes to some sensible categories of error. That might be an interesting "future" work that would be backward compatible to the shallow errors.

Somebody might care that this exists 👻