HI, A long long time ago (in a galaxy not too far away)...
The __plan__ was to not eliminate XML but relegate it to an import/export format, but to change the default "File" method to SQLite. The reasoning is that SQLite, unlike other SQL-based backends, provides the user with a single-file model similarly to XML. The user does not need to be a DBA to use SQLite. Indeed, using SQLite requires the same level of system administration knowledge as using XML. SO.. yes, the long-term goal is to move to using SQLite as the primary storage facility. In the interim, the plan (last I heard) was to migrate from QOF to an in-memory SQLite -- so you would load XML into an in-memory SQLite database and then gnucash would, internally, use that in-memory SQLite, and then "Save" would push the data back out to XML. From there, moving to a real on-disk SQLite would be easy. So yes, long term goal WAS to migrate to SQLite as primary backend; we would NOT remove XML, but there is a TON of work to get there first. -derek On Mon, September 14, 2020 10:46 am, Michael or Penny Novack wrote: > >> Is there a reason to keep supporting the XML file in future? Wouldn't it >> be easier to force save the data to SQlite to tackle the move from QOF? >> >> The benefit of point in time save (instead of transactional save) could >> be achieved by working from a copy instead. >> >> Probable issue would arise from users that read the XML file directly. >> > Here's my two cents. And I am perhaps a good person to stick my nose in > because of one of the issues raised. > > No, keep XML. > > a) A burden to require existing users to obtain and maintain SQLite. > > b) Don't forget that some of us, quite properly, have long term backups > of books << say the books after YE ab initio >> If gnucash were no > longer to support XML, we wold have to convert all of those. And since > the issue of "unalterable books" has been raised, I will point out that > these backups might be considered so -- made onto "write once" medium > and in "legal custody". Converting them to SQLite removes that guarantee > << how do you know that NOTHING else was done besides conversion, no > alterations of data >> > > c) The issue of those who manipulate the gnucash database (I am using in > the generic sense) directly OR extract feeds from it OR send feeds to > it. They would have to change all their stuff. And here's why I am an > especially good person to respond. In my working days I have DIRECTLY > modified an SQL database. Not SQLite but real SQL, DB2 on mainframe. Not > going into why this done was beyond saying during testing a MAJOR change > was made to a project, tables were added, and a need to populate the > redefined database with test data << done the "right way", lots of > people working many days entering one at a time from terminals -- even a > batch DB2 process would have been slow >> The point here is that I was > real sneaky. Out of the hundreds of IT people in this very large shop I > was perhaps the only one who could have thought of the trick I used. So > I would consider writing something to do this sort of thing way beyond > reasonable for even very skilled end users. > > > Michael D Novack > > PS: I might as well include a plus for SQLite at the same time. Probably > much less skill required (once having learned SQLite) to query the > database outside of gnucash. I would think that far easier than what I > would have to do to write a program to query when a XML file. > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
