2008/5/30 Derek Atkins <[EMAIL PROTECTED]>: > 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. >
For now the GDA team is realy limited in developers. Vivien, the main developer, concentrates its work on V4 witch is a major re-work of V3, most of the work on V3 it's stopped becouse at the moment other developers have no time enough to fix this bugs, I hope to they or even me find the time to work around V3. > 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? > Fixing bugs on V3 is mainly done by some users/developers still using it, I think any one have time enough to help to fix this bugs. GDA V4 helps to simplify most operations and create, execute and manipulate SQL queries in a simply way. > 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? > The developer must evalulate the alternatives and use it if he want it. But ofcourse this desition will be affected over the time frame you want to archive objectives. I know that this is not new, but just need to evaluate the alternatives, I realy don't know any thing about dbi, but why I think GDA V4 is a good choice: * It is based on GLib * It will be propoused to be included on GNOME * It's licended under LGPL * As others, is a layer to have access to a different DBS using the same code * As a GLib based library could be, more or less, easy to have bindings to different languages * V4, don't know V3, have XSLT transformations to access to data * You can use virtual connections, have access to a tables in a different DB as it was a local table; allows you, for example, copy data from a table in a MySQL to a PostgreSQL database. * And more.. * V3 has a more complicated set of objects, most of them removed for simplicity in V4 > 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. > In V3 if you try to create "by hand" a Query, you must use a lot of GObjects and properties to have a GdaQuery object, witch is realy complicated way to describe or understand its parts. On version 4, you have just a GObject called GdaStatement and a tree of C structures describing the SQL query parts, in a realy simple way. To see a better explanation about this look at GDA documentation (boulding from svn). But there are a lot of API/ABI changes to get a more easy to use library. > "Daniel Espinosa" <[EMAIL PROTECTED]> writes: > >> I've read all your other comments and is the same as before I "try" to >> re-write most of the GC's core, you don't want to lesen the others, >> the I don't plan to work on GC's as actualy is. If I can help Phil >> improving GDA it's Ok. If some others work to modify the GC's core to >> create a bussiness library and a GUI aplication I'll help. If the >> bussiness library is written to sue a DB, using GDA or not, I'll help. >> >> And please Derek, don't reply this if you want to insult or vociferous. >> >> 2008/5/26 Derek Atkins <[EMAIL PROTECTED]>: >>> Can't you just use "CREATE IF NOT EXIST" ? Or is that not portable enough >>> across various SQL implementations? >>> >>> Part of me is really thinking that GDA is more trouble than it's worth. >>> I'm sure Esodan will vociferously argue against this, but perhaps we >>> should drop GDA and choose something that actually works? >>> >>> -derek >>> >>> Quoting Phil Longstaff <[EMAIL PROTECTED]>: >>> >>>> Graham Leggett wrote: >>>>> Phil Longstaff wrote: >>>>> >>>>>> Well, V4 basically works with the sqlite provider. There were a number >>>>>> of memory leaks and other small issues. However, there are a number of >>>>>> problems with the V4 mysql provider - it's not ready for use. >>>>>> >>>>>> I've decided to switch back to V3 for now. I'll continue to supply >>>>>> patches and if I have to, I'll pull it into the tree under 'lib'. >>>>> >>>>> Considering that V3 is not being actively developed, and that bugfixes >>>>> to v3 won't be accepted, is it not safer to develop for V4, and get the >>>>> upstream project to fix any problems involved? How far away is the V4 >>>>> mysql provider? >>>> >>>> >>>> I don't know how far away the V4 provider is. They have a >>>> meta-information system which allows you to access info about the db >>>> structure (e.g. which tables exist) and the meta-information system has >>>> been redesigned for V4. It hasn't been implemented for mysql yet, so >>>> when gc starts, it tries to create all of the tables, even if they >>>> already exist. Note that it was a meta-information bug which was >>>> causing a problem in the gc-V3 code which was not accepted. The bug is >>>> that if you delete all db tables and then ask libgda to update the >>>> meta-information, it still thinks that the 2nd table exists (usually, >>>> billterms) so that it won't be created. This could happen when you are >>>> trying to save-as to a db, so billterms won't be saved, and lots of >>>> business objects will be screwed up. >>>> >>>> I see 3 possibilities: >>>> 1) Do libgda V3 maintenance ourselves by sending in patches and asking >>>> for them to be applied. For the particular bug I found, I didn't send >>>> in a patch, but asked for the bug to be fixed. Maybe they won't fix >>>> bugs but will apply patches. They would probably not create new >>>> tarballs, so anyone who wanted to use gc-libgda would need to check out >>>> the V3 trunk from svn and build from source. >>>> 2) Pull the libgda-V3 branch into the gc tree under lib. The GC team >>>> would maintain it. This has the advantage that it would not be an >>>> external dependency any longer, so anyone who wanted to try the gda >>>> backend could. The obvious disadvantage is a mess of code that nobody >>>> knows but that we need to maintain. Once libgda-V4 is further along, I >>>> can switch back to V4. >>>> 3) Change my decision and switch back to V4. I have basic operation >>>> with sqlite working. There is at least 1 regression (I can't create the >>>> index on the slots table) which would have performance implications. I >>>> don't know where the problem with index creation is. However, there are >>>> some improvements. The libgda-V4 statement structures can represent SQL >>>> operations which were not possible in V3, and which would improve >>>> performance. However, as I said above, the mysql provider is missing >>>> some major functionality. I don't know about postgresql. >>>> >>>> There are other issues with the whole gda backend which I need to work >>>> on and which are independent of which version of libgda is used: >>>> 1) some of the dialogs (e.g. price editor) create an object when the >>>> dialog is opened and then modify it as the dialog is used. This can >>>> cause commit requests for objects which break db constraints (a price >>>> must have a commodity, but a save request may come before the commodity >>>> is set). Fixing this requires a change to db logic to only create the >>>> object when 'OK' is pressed. >>>> 2) versions for tables and handling of version updates >>>> >>>> I had decided to stay with V3 because it would not be a step backwards >>>> in functionality. I wanted to try V4 to see what shape it was in, to >>>> get some experience with it, and to provide some feedback to the >>>> developers before they release. >>>> >>>> I think I'll stay with V3 for now and monitor V4. When they implement >>>> the V4 mysql meta-info code, I'll reconsider switching. I'll also do a >>>> bit of testing to see how postgresql looks. >>>> >>>> Phil >>>> >>>> _______________________________________________ >>>> gnucash-devel mailing list >>>> gnucash-devel@gnucash.org >>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >>>> >>> >>> >>> >>> -- >>> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >>> Member, MIT Student Information Processing Board (SIPB) >>> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >>> [EMAIL PROTECTED] PGP key available >>> >>> _______________________________________________ >>> gnucash-devel mailing list >>> gnucash-devel@gnucash.org >>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >>> >> >> >> >> -- >> Trabajar, la mejor arma para tu superación >> "de grano en grano, se hace la arena" (R) (entrámite, pero para los >> cuates: LIBRE) >> >> > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > [EMAIL PROTECTED] PGP key available > -- Trabajar, la mejor arma para tu superación "de grano en grano, se hace la arena" (R) (entrámite, pero para los cuates: LIBRE) _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
