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? 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? 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. -derek "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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
