kinterbasdb: My Update

Phew.

It’s been a pretty interesting “first day” of releases. I have to admit to myself that I hadn’t quite been organised enough and merged two bug-fixes into the main source tree (did I lose applying them somewhere between work and home? I need to stop having three CVS repositories and carry just one around on CompactFlash!).

Perhaps something which was meta-CVS (CVS for CVS?) which allowed you to merge CVS trees would be an amazing tool for multi-homed people like me? The alternative would be if work had a 24/7 internet connection — I could do all my development work “from” there. Bah. The world isn’t perfect.

So I had to settle with two “releases” in a day (I knew that the first one wouldn’t be perfect, somehow, so calling it rc1 was a good thing!). Not what I wanted to do, but I’d rather do that than keep track of all the versions people could have of CVS files.

I am pleased with how much progress I’ve made so far on kidb-3.0. A lot of code has been updated. A lot of features have been tidied up. I’ve learned a lot more about the whole isc_blah() interfaces, mainly through sitting down and thinking about how to encapsulate everything into objects.

I’ve got to find a win32 machine to do testing on — I’m concerned that this could be a big failing of mine at the moment. However, with access to a FreeBSD box, I’m hoping to open up kidb to another OS.

I’m very concerned about Interbase on non-x86 platforms — 64-bit machines, for instance. Who knows, even endianness could be a problem as it stands? I really need to delve a lot deeper into the code than the main part of work I did this last week. A lot of the code seems to rely on 32-bit words, I think. A whole load of work will be required on the build-farm to test this. But that’s something for a future time — perhaps for when there is a need?

My brief timeline:

• rip out constants from kinterbasdb.py (shuffled to the top of my priority list because someone else thought of it first!)
• see what can be done about mx.datetime’s new versions — probably mirroring a known working version’s source here will be appropriate, but suggesting that people download a more up-to-date version from the mx site. I remember having problems trying to get the latest version, because I’d chosen the day or two when the site was moving and half the files didn’t seem to be there! Again, near the top of the priority list, because I’ve wanted to do it and somebody else has mentioned it to me.
• documentation documentation documentation documentation — there are days’ worth of typing here, and I will certainly need a hand!
• release kidb-3.0 final version back-port fixes from kidb-3.0 to kidb-2.1 (new version number) for people who don’t want these new features
• make a BSD port of kidb-3.0
• start work on kidb-3.1 — select by name, connections and transactions (separating the two, if possible — testing “in the lab” required — so that multiple transactions can happen down one connection to the database, thus lightening the process-load on Firebird classic servers — not a problem for Windows users, because all their Interbase/Firebird processes are threaded [superservers] not forked [classic])
• increase the thread-safety level of kidb. Allow threads to share connections (currently I worry about the concurrent creation and destruction of cursors within two threads sharing the same connection — I need to prove to myself what the locking semantics and reference count modifiers, py_incref and py_decref exactly do).

I think that’s all I’ve got in my head right now. I’m sure to do some more brain-dumps in here though. Time for bed, to dream about how brilliant everything will be when it’s all finished.

Side-note: any work done on kidb-x.x on monday will suffer from Six Degrees of Inner Turbulence: it’s out in the uk on Monday, and it’s ten minutes’ walk from work to the shop where I pre-ordered it.

Headphones are already packed.