[GNC-dev] Deprecation of XML file

[jean laroche]

I too like the ability to manipulate the xml file directly, so I'm 
attached to it.
Can someone explain the benefits of SQL vs XML?
Is it faster?
I know it allows simultaneous access by multiple users, but is that a 
realistic usage scenario for GC?
Would it help implementing a real undo/redo mechanism? (something that I 
do think is sorely missing)
Jean


On 9/14/2020 8:07 AM, Derek Atkins wrote:
> 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
>>
>