On Fri, Dec 02, 2011 at 03:01:37PM +0100, Pavel Cisar wrote: > 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...
Well my vote is to create new git fork for pyfirebirdsql and then to merge your work there and push it back in a branch It's a lot easier to develop on github and i guess anyone can join and improve it after first commits are online > > best regards > Pavel Cisar > IBPhoenix > > > ------------------------------------ > > Yahoo! Groups Links > > >
