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:: mlacunza@...
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: mlacunzav@... 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
>
>
>
>