Linux support for Firebird need Commit function

[obsidian-studios]

Ok I am connect to my Firebird database and have a initial Firebird for Linux nwnx plugin. However I do not want my connections to be auto commit. I see no current support for a commit function. I am about to add a virtual commit function in data.h/data.cpp so I can add support for it in sub classes. Is there some other place I can add the code to commit transactions etc? In a more generic way.

Curious if virtual SQLCommit function is in the future for linnwnx2? I would like to help develop linnwnx2. If not part of the main version I guess I will have my own port of linnwnx with a bit of transaction support and a plugin for Firebird.

Let me know if you are interested in help test the Firebird plugin, or would like to use it in the furture.

[NoMercy]

Firebird requires out of band transaction controls? It seems odd that where most other databases can handle transactions from nwscript by issing COMMIT/BEGIN/ROLLBACK statements.

[obsidian-studios]

I am just going by the base code I see and I see no way for a commit request to be passed from script to firebird. I am adding the ability now, I put code in the base classes that my plugin inherits, and in my plugin so there is abilty for commit and rollback. I had to go though and change all NWNX! function calls from ODBC to firebird since the plugin is compiled and loaded as nwnx_firebird.so. The current one should do the same since there is no odbc stuff in the nwnx_odbc.so. That really should be nwnx_mysql.so, and all script calls changed from NWNX!ODBC to NWNX!MYSQL.
IMHO

[NoMercy]

I would argue that all 3 plugins, ODBC/MySQL/Firebird should all use the NWNX!ODBC message just for the sake of making it easier for people to run one module on diferent types of database.

And... how does Firebird handle transactions?

[obsidian-studios]

Not really an argument but what you are mentioning is a pain for a few reasons. One you would have to have a make file that could compile either MySQL or Firebird as nwnx_odbc.so. Depending one which one they want support for. Further more since neither on linux has anything to do with ODBC why it should be called nwnx_odbc.so in the first place. nwnx_odbc.so on linux should be reserved for the plugin that provides ODBC support. So you could use a odbc driver for any database. Or use a plugin that is specific for your database.

Also since like 90% of the aps_include is a starting point and will be modified for my needs. Very few of those fuctions wiil be used unmodified. It is trivial to quickly via search and replace, find and replace all occuances of ODBC with eihter MYSQL or FIREBIRD.

Also with regard to database, I do no think it should be easy. Once again we are talking about people running linux in the first place. So why not have features in plugins that access database directly via their respective API's have calls and etc that take advantage of the direct access.

IMHO

[JeroenB]

Have a look at the windows version of the ODBC plugin. It also has support for multiple database systems. And it is no problem at all to link it to different database systems (as without ODBC connectivity).

The name is just historically, and should be usd to make it easier for other people to use. So, please keep using the NWNX!ODBC messages.

Look it like this: you run firebird, then a new much faster database gets released. Before you can use it you have to change all the occurences of the message to support the other system, what no much people want to do (and they might already have an ODBC base lying there).

[obsidian-studios]

I am not concerned with the windows versions. I am sure there are many ways to go about it. For those that insist on being lazy you can just take my nwnx_firebird.so plugin and rename it to nwnx_odbc.so.
Problem solved.

I am lazy myself but calling and using the string ODBC in something that has nothing to do with ODBC is just pointless to me. I will not do it. Once again it is extremely quick and easy to edit the aps_include file and replace all occurances of ODBC.

Like if you use other plugins with nwnx, that is exactly how you call them. So since I am making a firebird plugin that is not ODBC related, it make sense to be using the string FIREBIRD instead of ODBC in my nwn db scripts.

No one has to use my firebird plugin. If they do they can do it my way, or make the effor to do it there way. Since I am writing to code to add fireird support in the first place.

Oh and by the way, one of the many reasons I run Firebird the engine foundation is around 20+ years old. So nwn and my mod will be way outdated before I decide to switch RDBMS. I would not be going through all this if I could be swayed.

[NoMercy]

Guess we could insert a mapping which allowed either the old "ODBC" for backwards compatability and a "SQL" for future use to be mapped to whichever database can provide SQL functionality... but that's probaby going a bit far :)

[obsidian-studios]

FYI, the firebird plugin is done and I have been using it and testing it now for like a week. Still got to add blob write support and there is no support for arrays, either read or write. Otherwise there is support for all other data formats.

Not sure what to do with it now? Other than use it for my needs

[NoMercy]

post it up somewhere with the code, then someones bound to butcher it to how they believe the universe should look, and put it into nwnx or some other GPL product :)

[PlasmaJohn]

Right before I wandered off to do other things (like actually play the game ) I was considering a sub-plugin architecture for database support. In a nutshell, the nwnx_odbc plugin would be the glue layer between nwnx and the database driver of choice allowing the NWScript side to be able to develop against a common API. Basically the engine independence of "real" ODBC with the performance of direct API support.

[obsidian-studios]

You can do all that but I think it's a bit extreme. I think it makes more sense to treat each as a separate plugin or come up with a more general name. With nwnx_odbc.so reserved for the plugin that provides odbc database support for any db with a odbc driver. I think the mysql and firebird ones should be named and called nwnx_mysql.so and nwnx_firebird.so.

In fact I changed my plugin so it no longer requires any changes to the inherited base stuff. Then all you have to do is change the ODBC stuff to FIREBIRD with a simple search and replace.

This allows you to make calls like NWNX!FIREBIRD!COMMIT, NWNX!FIREBIRD!ROLLBACK, NWNX!FIREBIRD!PREPARE, NWNX!FIREBIRD!BLOB, and more. Which makes more sense than ODBC, Since I know I am using the Firebird plugin via nwnx and it's calls.

I am finishing off the blob write support now and should have the plugin ready to go within a day or two. I would like to see it available as a plugin for nwnx on linux but not part of the core linnwnx2. If it is part of the core the abliity to compile it or not. Of course with it's own documentation.

It's not my intention for it to be easy to switch among database for comparision etc. There are to many differences IMHO and direct API plugins should reflect that. Completely the opposite if it were a general ODBC driver plugin for any database with a odbc driver.

Up to you although just my two cents and contributions via firebird plugin.

[NoMercy]

What exactly do you do with a BLOB in NWN, the windows version uses them for GFF data, but there's no hooks for that in the linux version so far as I know.

[obsidian-studios]

I am not sure? I am still somewhat knew to mod building. I was thinking to provide means to store items via a bank box or something like that. Or other abitrary length data. I just came across parts of the aps_include file where it was storing an object. So I figured if I wanted to store object directly without conversion to some other form I would need binary blob support?

If I can caputure user input I would like to have the ability to report bugs within the game. I have a few other idea but those are the main two. I am not sure if the storecampaign object is a local storage function call or remote? I would have to look at the source code to be sure, but I am trying to basically replace the following functionality.

SetLocalString(GetModule(), "NWNX!ODBC!SETSCORCOSQL", sSQL);
StoreCampaignObject ("NWNX", "-", oObject);

The first part I know goes to nwnx but the second? Seems they are linked because the first ones sSQL string containts a ? for a value. Which usually states blob or some other data to be filled in later, before sql execution.

[NoMercy]

*nods* That's part of the object saving and loading part of odbc2 SCO/RCO are the names of the hooks for it, not totally sure what they stand for, probably something like Store/Read Coded Object.