Derek Atkins wrote: > Daniel, > > My major concern here is that a year ago you were rallying for > GDA and GdaQuery. Phil threw out a bunch of his work to target > GDA-3 with GdaQuery. Now here we are, 6 or 9 months later, and > the GDA team has moved on to GDA-4 already and are dropping GdaQuery, > the very interface you were so adamant was the greatest thing > since sliced bread. Phil has found a number of apparently major > bugs in GDA-3 which the GDA team seems reluctant to fix, and GDA-4 > isn't nearly as usable as GDA-3. > > So, what's Phil supposed to do? Work with GDA-3 with the known > bugs, knowing that those bugs will never be fixed? Work with GDA-4 > which is just broken and cant be tested and hope that the GDA team > gets it working and makes a release early enough that GnuCash can > actually use it?
If we stay with GDA-3, Daniel could provide fixes (or could commit fixes), but there's no guarantee that there would be any more releases. My suggestion to include GDA-3 in the GC tree was simply so that we *could* guarantee and rely on GDA releases, namely, our own, and our dependencies would then be on sqlite, mysql and pgsql libraries. If or when GDA-4 is solid enough and released or soon-to-be released, we could switch to it. It seems to me to be similar to some of the libraries which lived under lib for awhile (e.g. goffice-0.0.4). > Or would it be more expedient to pick a technology that has a proven > track record, proven stability, is NOT a moving target, and is > already available in most distributions? One problem with libdbi is that its scope doesn't cover everything that libgda's does. From what I can tell, libdbi doesn't have any apis to cover table/index creation, and that is one area that has a lot of individuality (e.g. autoinc integer fields). > Why did the GDA team decide to drop GdaQuery? And why did the > move to GDA-4 break all the backends? That seems like a very > bad idea to me. >From an e-mail on the gnome-db developer mailing list: On Wed, 2008-03-19 at 22:37 +0100, Vivien Malerba wrote: > > After a long time, I'm pleased to announce the first version of Libgda > > which will lead to a V4. This version is a major rework of the > > library's internals to correct the conception errors that were made > > with previous versions; it also aims at having a smaller yet more > > powerfull and easier to understand API, and to close some long > > standing bugs. > > > > A non detailled list of changes is: > > - Easier to understand and to use API, with less strange path usage > > - Reduce the size of the library (almost half the size and half the symbols) > > - Easier connection opening (removal of the GdaClient object) > > - Merge of the GdaQuery and GdaCommand into only one object to > > represent statements > > - New adaptative SQL parser (can be adaptated to each DBMS's SQL syntax) > > - New database based dictionary which can handle namespaces > > - Rework of the database adaptators (providers) for easier > > maintenance and more features > > - Sample "skeleton" database adaptators to make it easy to write a > > database adaptator for a new > > database type > > - Updated documentation > > > > A few warnings however: > > - This is still an early version which probably has a lot of bugs and > > as such it should not be used > > in a production environment. > > - Most of the database adaptators (providers) need to be re-written, > > particularly MySQL (which is > > currently being done) and Oracle > > - Libgnomedb has not yet been updated and won't compile with this version One problem (which I just asked about on the gda list) is why GDA-3 isn't being maintained while GDA-4 is being worked on. Phil _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
