[GNC-dev] Deprecation of XML file

[Derek Atkins]

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 at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


-- 
       Derek Atkins                 617-623-3745
       derek at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant