So...In the end, what's our options? 1. Use GDA V3. We will spend time fixing bugs in V3 that will probably not be released in a bugfix release of GDA. The advantages of this approach are that we get access to sqlite, mysql, and postgres. The disadvantage is that we will probably have to ship our own version of GDA, and in a few years, this will probably be out of date, requiring the switch to V4 anyway. We will expend significant energy to have it working "now", much of this energy will be lost when moving to V4.
2. Use GDA V4. We will probably send time fixing bugs here, but we are almost guaranteed that a release will happen. The advantages of this approach is that we will be current with the new GDA and releases will be done for us (or in conjunction with us - depending on how closely we work with the GDA team). Work done here will not be towards a dieing version. The disadvantages are that we will probably be limited to sqlite until the other providers are completed. We may have to distribute pre-release versions of the code until there is a 4.0 release, but after that, we hand it over to the "official" releases. 3. Use Libdbi/another approach. Advantages: we hope they are more stable and bug free, but do not know. Disadvantages: we have to re-do all the work done to integrate GDA :(. My personal opinion is that we go with #2, use GDA V4. We will need to do fixes in either #1 or #2. From a maintenance point of view it's better to put those fixes towards a version that has a reasonable chance of a release. (This does, of course, assume that V4 actually gets completed). At best the other providers get implemented and we have all of them available. At worst, we're stuck with sqlite for a while. If we really need mysql/postgres right away - it's going to involve significant work regardless of the option chosen. Phil, do you have a preference? It's probably your preference that counts ;) Nathan On Fri, May 30, 2008 at 3:41 PM, Charles Day <[EMAIL PROTECTED]> wrote: > Getting back to the gda stuff, the key question seems to be: Can support > for > mysql and postgresql wait? > > If so, then V4 seems like a good choice to me, since Phil has said (I > think) > that it works well enough with sqlite for our purposes. Support for the > other databases can be added as V4 evolves. > > I got the impression from the various updates over past weeks that V3 > wasn't > satisfactory for even ONE of sqlite, mysql, or postgresql -- unless we fork > it off and customize it. > > My $0.02, but since I'm not contributing to this part of GnuCash, feel free > to ignore it. > > Cheers, > Charles > _______________________________________________ > gnucash-devel mailing list > [email protected] > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > -- <><><><><><><><><><><><><><><> "Even if you are on the right track, you'll get run over if you just sit there" - Will Rogers _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
