Hello, First of all: its a great new! for some problems wit the old driver and not new dev job with the actuals I need to take the decision of migrate to other DB for most of my projects.
Pavel I think your idea is nice, Im expecting the opinion from the dev of the other driver. In my point of view have 3 drivers for KI is too much I think keep one and strong one is the best idea. I can help in the test phase if thats necessary. Saludos / Best regards Mario Lacunza Email:: mlacu...@gmail.com Personal Website:: http://www.lacunza.biz/ OpenOffice.org:: http://es.openoffice.org/ OpenOffice.org Perú:: http://openoffice-peru.com/ Hosting:: http://mlv-host.com/ Mascotas Perdidas:: http://mascotas-perdidas.com/ Google Talk: mlacunzav Skype: mlacunzav MSN: mlacun...@hotmail.com Y! messenger: mlacunzav On 02/12/11 09:01, 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... > > best regards > Pavel Cisar > IBPhoenix > > > ------------------------------------ > > Yahoo! Groups Links > > > >
