[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [Kexi-devel] libpqxx 2.6.9 breaks kexi's pqxx driver
From:       Jarosław_Staniek <js () iidea ! pl>
Date:       2007-02-10 23:51:39
Message-ID: 200702110051.39735.js () iidea ! pl
[Download RAW message or body]

Michael Nottebrock wrote:

>> > I'll take a look, but give me a few days
>>
>> We're using public pqxx's API, right?
>> Michaael, what pqxx version are you talking about? If they broke source
>> compatibility in a minor release, then it's not our fault...
> 
> To quote their release notes:
> 
> "Many things have changed. Bugs have been fixed, new features
> have been introduced. But most importantly, we're really retiring
> the old 1.x-style libpqxx API now. This API (where upper-case letters
> were still used in function names and such) has been supported for
> more than three years in the interest of backwards compatibility,
> but has been marked as obsolete all this time."

Michael, thanks for the info.

I consider these API changes as ugly step. Ugly enough to make us depend on 
<=2.6.8 and add a notice to packagers about avoiding packaging 2.6.9. I am 
suggesting to go this way. 

Moreover, with (the last official, before 2.0!) release coming next week, we 
have no time and power to test such a nontrivial jump, and this is even 
against of our policy related to minor releases. Example: mysql client lib 
can be upgraded on a target system without negative implications to KexiDB.

Also note that pqxx usage in Kexi 2.0 will be most likely dropped in favour of 
libpq. It has become more and more hard to wrap one C++ API (pqxx) within 
another (kexidb) without any clear benefit, but with code obfuscated. For 
instance, we do not need 'intelligent' db cursors coming from pqxx because 
KexiDB impelements them from scratch. Pqxx can be nice to use in apps, but 
again: it's hard to wrap and I'd say it will be even harder as pqxx become 
more object-oriented. That's not even pqxx fault.
In 1.6.x, despite superiority of postgesql as a backend, mysql support is 
better, more stable than pgsql.

Please correct me, but I still do not believe the developers decided not to 
jump to 2.7 or even 3.0 version before such a change (ABI is thus badly 
broken as well). It's like TT would DROP Qt3 Support module one night...

Summing, up I propose to do nothing in terms of coding (perhaps except a 
configure check against the 2.6.9 version).

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
 Kexi & KOffice: http://www.kexi-project.org, http://www.koffice.org
 KDE3 & KDE4 Libraries for MS Windows: http://kdelibs.com, http://www.kde.org
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]