El vie, 02-12-2011 a las 15:01 +0100, Pavel Cisar escribió:

> Hi all,
>
> Those who attended my "Python drivers" session at conference in
> Luxembourg already know that last two months I have worked on another
> Python driver for Firebird (codename fdb). It was just an experiment how
> far I could go in short time with another approach to implementation,
> not real attempt to replace both existing drivers (KInterbasDB and
> firebirdsql). However, it went so well, that we have a real chance to
> get out a truly universal pure Python driver for Firebird next year.
> Here are details...
>
> The *fdb* driver is based on my old experiments (back in 2009) with
> ctypes interface to Firebird. Back then it ended with ibase.py interface
> and very basic connection and transaction classes, and ability to make a
> connection and start a transaction. Over last month I was able to
> implement full DB API 2.0 Spec + some extra.
>
> - Connection, including drop and create database
> - Transaction, incl. multiple transaction per connection, transaction
> parameters, savepoints and retaining.
> - Cursor. Fully supports materialized BLOBs, input parameters (incl.
> BLOBs), should handle dialect 1 gracefully (but it wasn't thoroughly
> tested), has row mappings and iterator protocol support built-in,
> automatic unicode/connection charset conversions.
> - Services. All what KInterbasDB 3.3.0 supports (i.e. all except TRACE).
>
> What is missing:
>
> - Prepared Statements (some work done, but unfinished).
> - db_info API calls
> - Support for streamed BLOBs
> - Support for Firebird Events
> - Distributed transactions
> - Trace API Service support
> - Support for Firebird arrays
>
> I'm going to finish the prepared statements and db_info call, add some
> basic documentation and import sources to Firebird Projects Subversion
> repository this month (hopefully before Christmas). Next I'd like adapt
> KInterbasDB unit test for new driver. I wrote several unit tests myself
> for new driver, but using KDB ones would help us to set a reference for
> next development as the primary goal is to make the driver as much
> compatible with KInterbasDB as possible, so existing applications
> (specifically Firebird QA tool-chain) could be easily ported to new one.
>
> At this stage (sometime in January) we should have fully functional beta
> driver suitable for 95% of tasks based on ctypes (FB client library). As
> both ctypes and wire protocol interfaces have their distinct advantages
> and disadvantages, I'd like propose to unify *fdb* and *firebirdsql*
> into single, official Firebird driver for Python, housed at Firebird
> Project (under name firebirdsql). The idea is that at that point (end of
> January) we should have enough functionality and unit tests implemented
> to start work on *inner* interface to talk with Firebird engine, that
> would allow us to have single higher level core with two "communication"
> implementations, one based on ctypes, and one based on wire protocol
> (and eventually third one using new object interface provided by FB 3.0,
> btw first alpha of 3.0 should be released in Q2/2012).
>
> In parallel with these unification works, I will continue to implement
> the remaining features, namely streamed BLOBs, events and distributed
> transactions. If Hajime would agree to join our efforts and merge the
> drivers, we should also easily get (and keep) support for Python
> 2.x/3.x, as his primary development platform is Python 3 and mine is
> still 2 (2.6 to be precise).
>
> So, that's the current situation and plans for future. Any comments are
> welcome...

Hey, greats news!
I hope the whole python-firebird community push this effort.
By my side, I can't wait for any stable version to implement into
django-firebird in replacement of kinterbasedb ;)

Regards.
--
Maxi