[Kexi-devel] Firebird Driver - Stutus Report

[Gianni Rossi]

On Wednesday 19 October 2005 19:24, Martin Ellis wrote:
> On Wednesday 19 October 2005 20:18, Gianni Rossi wrote:
> > Basically, I've retro-fitted all the code I had from other classes into
> > the KexiDB::driver, KexiDB::Connection and KexiDB::cursor
>
> You've copied code from somewhere?  Where?
> What do you mean by 'other classes'?

Sorry, this is a 'continuation' of a conversation that started in prvate with 
Jaroslaw...

I had previously created a set of C++ classes to work with fb.  I'm basically 
copy/pasting this code into the KexiDB API.

>
> > The "external" files/classes remaining are:
> >
> > - fbclientlib: class that does the actual calls to the firebird or
> > interbase library.  It tries to find the library and loads it dynamically
> > (i.e. dlopen() / LoadLibrary() ).  This enables it to load either the
> > fbembeded library or the "normal" fbclient library, as well as
> > interbase's gds32 library.  If it manages to find a fbembed library, it
> > will support direct file-access as well as server acess to FB1.5.X,
> > FB1.0.X, Interbase 6.X  I haven't tested with other versions.  This class
> > implements all the low-level API calls as virtual-QT-friendly functions,
> > since API changes are expected in the near futre, it should just be a
> > matter of overriding a few functions, and the library should be backwards
> > and forward compatible by just checking the version-info returned by fb's
> > library and loading the corresponding class.
>
> Sounds like this class should be wrapped by the FirebirdConnection and (to
> some extent) FirebirdDriver classes?

This class works mainly as a general-purpose fb/ib entry point, and just 
handles the API calls, and in the future, handling the minor diferences 
between diffrent library versions.  Also, the fb API has some nasty little 
details; all of which I think is better to handle in a single location.  It 
doesn't do much apart from converting QStrings to char*'s, calling libs, 
etc...

>
> > - fbXSQLDA: class that handles fb's "extended SQL descriptor" which is
> > basically results' columns and input SQL parameters.  This class extracts
> > the data from the result-set.  From what I've seen, MySQL and SQLite
> > returns data as strings?  The XSQLDA returns data in severall formats.
> >
> > - fbblob: class to handle the special case XSQLDA; blobs... :-)
>
> Presumably the FirebirdCursor class wraps these classes.
>
Yes.  I guess, in the near future it could be fitted into the FBCursorData 
class?

> The MySQL driver definitely doesn't return data as char*'s - in fact the
> rowData function just does "return 0;"- although I think the SQLite driver
> might (can't remember).
>
> See the MySQLCursor::value(int) function for how MySQL does it. (I'm not
> sure why we do case distinction on types here, and not in KexiDB, but we
> do)
Yes I've seen it, and I guess it should be just a case of 'forwarding' the 
call from FBCursor::value(int) to fbXSQLDA::value(int).  Again, as mentioned 
above, XSQLDA class could become FBCursorData

>
> > - fbtypes: Old type defenitions... should be gone soon.
>
> OK.  Ignore that for the moment then.
>
> > The only "big" things left are:
> > - parsing the fbkeywords.y file (I've no idea how to do this)
>
> What does that file contain?
>
> > - get it to compile
>
> That'd be good. :o)
>
> > - test!
>
> See the kexi/tests/newapi directory for testing DB drivers.
>
> I'd ignore the mysqlcursor stuff there.  It's from before I rewrote the
> MySQL driver.
>
> Feel free to send me what you've got, if you want to check you're on
> roughly the right lines, and just shout if you get stuck.
>
> Cheers
> Martin
> _______________________________________________
> Kexi-devel mailing list
> Kexi-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kexi-devel

-- 

IM talk.google.com: nasus.maximos at gmail.com