[GNC-dev] Deprecation of XML file

Stefan Bluhm gnucash.org at bluhm-de.com
Mon Sep 14 15:38:27 EDT 2020


Thank you all for the feedback. Let me please summarise your demands for XML and comment on that (I hope I didn't leave any comments out). Always keep in mind that in this case we are talking SQLite as a file type, just like XML. Not about the DB server library.

1) A save file has less management overhead than a DB.
> SQLite is also file based and transparent for the end user. No DB management required. So here is no chance a tall.

2) Save file can be distributed via fileshare.
> SQLite is also file based and transparent for the end user. No DB management required. So here is no chance a tall.

3) It can be easy analyzed by a simple grep commands
> This would become a little more complex but can be done: sqlite3 file.gnucash .dump | grep "text"

4) It can be easy analyzed by more advanced (XSLT, XPATH,…) commands.
> Just use any SQLite browser. I claim that is a lot easier than fighting with XSLT/XPATH etc (this is certainly opinion based)

5) Use rsync for fast diff based backups.
> Should the same with an SQLite.

6) XML is a well defined format, while SQLite is not ISO complete.
> SQLite also has a defined file format. It might not be an ISO standard but it is well defined.

7) A burden to require existing users to obtain and maintain SQLite. Other SQLs have their additional administrative overhead.
> There is no additional administrative overhead (assuming the DBI library is included in GnuCash).

8) XML files are used as long term backup. A conversion risks the guarantee that nothing has changed between opening.
> This is a process question. It is risky to expect your software to never change file structure just because the content should be archived for a long period of time.
To archive, the data should be stored in an archive-able format (CSV/PDF-A) and maybe also with the software that can read those files (although OS might change)

9) Users who have build their own interfaces to the file will have to adapt their custom interfaces
> These are part of the technical debts if you go down that route. Documentation specifically states to not do that. Apart from that, I claim that interacting with the file via SQL is a lot easier than XML parsing (but that is again just opinion).



The reason why I am bringing up this topic is exactly, as Derek states: Moving into the direction multi-user support. SQLite is not the solution but I see it as a step into that direction. Including simplifying the complexity.

I would only see point 8 above as a relevant point for XML.

Small step 1 for me would be to allow import/open of XML file but save only as SQLite. This would secure GnuCash for the above archiving purposes but prepare all future save files as SQLite only. Now we have plenty of time to complete the migration away from QOF. If we allow import only (and expect a destination working FILE), we might even get around the in-memory SQLite DB.

Now we can decide what step 2 is and work on that with less risk/a solid base. Maybe parallel SQL and QOF implementation? Or the bit by bit SQL migration? Or full QOF replacement.


What are your thoughts on that approach?


Best wishes,

Stefan


----- Ursprüngliche Mail -----
Von: "Stefan Bluhm" <gnucash.org at bluhm-de.com>
An: "gnucash-devel" <gnucash-devel at gnucash.org>
Gesendet: Montag, 14. September 2020 08:11:09
Betreff: [GNC-dev] Deprecation of XML file

Hello GnuCash Team,

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.

Let me know your thoughts.

Best wishes,

Stefan
_______________________________________________
gnucash-devel mailing list
gnucash-devel at gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


More information about the gnucash-devel mailing list