On Sat, 2004-03-06 at 11:07 -0600, Linas Vepstas wrote: > On Fri, Mar 05, 2004 at 05:27:32PM +0100, Rodrigo Moya was heard to remark: > > so, your database is a XML file then? > > gnucash supports the storage of data in both xml and sql. > and what API does it use for the sql case?
> > libdbi does what libgda does, so there's no point in using one from the > > other. > > OK, then I misunderstand libgda. > right, indeed, if your opinions were based on the 3-or-more-years-old 0.2.96, I guess you don't know libgda at all. Current libgda (1.0.x) is totally different from the GNOME 1.4-based one. > libpg and ODBC and libdbi are low-level communications > libraries that do not offer any sort of abstraction, they're > just straight-ahead API's for SQL database acess. They are > adequate for what they do. > right, libgda is that, and a bit more. We are trying to make libgda a "perfect" data access and management, so the goal is not just to be a low-level abstraction, but a high-level one, accompanied with utilities classes and functions to easily manage the data. > But I thought the goal of libgda was to provide a set of high-level > abstractions to multiple data sources, including sql and xml and ldap, > which would imply that libgda is comparable to other high-level > abstraction libraries. But maybe that is libmergeant. > libgda provides, again, a level of abstraction over different RDBMS (including non-databases, like XML files, ldap servers, etc). libgnomedb is a set of simple widgets to display and manage DB data accessed via libgda. libmergeant provides a data dictionary, using both libgda and libgnomedb, which makes it really easy to develop apps that manage the data in different data sources, with extra things like cache, updatable widgets (that send the modifications made by the user automatically to the underlying DB) and other goodies. Development of libmergeant is now separate, but it will probably be integrated into libgda (non-UI parts) and libgnomedb (widgets) as soon as it's ready. > Finding the correct high-level abstraction is difficult, which > is why I kept harping on bond and gnue and qof and dwi. > None of those packages do it all, they're all shit, they've > all got major faults and shortcomings, but they're all > that we have today . > right, so we probably should come up with a solution that fits everyone's needs? Thats the intention of gnome-db, longer term, but we add features a step at a time, because we want to have solutions implemented and designed by the people who need them, instead of doing yet-another-custom-made solution that only fits our needs. That's why I've been asking about how to better integrate everything. Some progress, as I already said, was done with bonddb and papyruys, although still needs a lot of work. > It would be very nice to have a > database abstraction layer that combined the best features > and aspects from bond and gnue and qof and dwi (and mergeant > too I guess). I was hoping to have a conversation about > the high-level database abstraction layer. > this conversation was about that. libgda provides that abstraction layer (with all its shortcomings, of course, which is why we need to know what you need from it, so that we can add it), so it makes sense to at least start sharing technology for that. Of course, IMHO. cheers _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
