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.