Re: [GNC-dev] Deprecation of XML file
On Mon, 14 Sep 2020 at 14:18, Stefan Bluhm wrote: > > Is there a reason to keep supporting the XML file in future? More than "a reason", singular. Here are two that come to my mind, based on past usage: 1) It's a lot simpler to perform XSLT actions on an XML file than it is an SQLite file 2) You don't need any SQL-aware tools to inspect or manipulate an XML file, just a plain-text aware pager or editor does the job. As for the more recent, > Let me please summarise your demands for XML ,,, well, the "demand" here would appear to be the one that would no longer see XML supported. Perhaps it would be better if you would, instead, summarised the benefits, as you see them, of taking XML away, noting of course that suggestions akin to "well, you could still do X but would just have to do it with S" will rarely be seen as beneficial by those who are already doing X. Is there perhaps, something that you want to do with the codebase that you are currently unable to do, because you have to write it out to an XML file when you come to save, or would not be able to read in from an XML file when opening? Just my tre'pen'th though: and probably not worth even that in "new money"! ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Deprecation of XML file
Just my 2p here. I am a staunch XML user... despite its flaws and too many
namespaces, it has simplicity in viewing/editing with any text editor.
Save/Reload can be done safely with SQLite Rollback mechanism
https://sqlite.org/wal.html -- with this facility I'd expect that datafile
modification (e.g. transaction commits, transaction modification, business
object posting, etc) would be instantaneous, yet Ctrl-S would create a
checkpoint ("Data saved on 2020-09-15 12:06pm") to which I would then be
able to rollback anytime. Rollbacks would be read-only by default, and I'd
want facility to "revert to checkpoint". The atomic change would ideally be
highlightable in UI.
So, I'd not be opposed to migration to SQlite by default, and XML
imports/exports if someone will create an ironclad implementation. SMOP!
On Tue, 15 Sep 2020, 10:04 am Mike Evans, wrote:
>
> > The *main* benefit of SQL storage is that you get immediate saves. I.e.,
> > when you commit a transaction, it gets saved to storage immediately. So
> > -- no lost work.
>
> This is exactly why I *don't* use a database for storage. I often screw up
> entering data. I don't save until I'm happy I've done it right. With XML
> I can just reload the file and try again. With a database I'd have to
> restore the last backup, probably yesterday's, then restart GnuCash and try
> again losing *everything* I did today. (Yes I could manually do a backup of
> the sqlite file after each transaction but...). With XML I can enter a
> transaction, check that I've not screwed up, save the file, then move on to
> the next transaction, check it and save. This way If I screw up I can
> simply reload the XML from however many minutes ago I last saved and
> continue.
>
> The no-lost-work maybe fine for some|many but not for me. The only
> immediate advantage of a DB backend is (as far as I can see) is concurrent
> user access, which GnuCash doesn't do, yet, so until then I will be using
> the XML file storage. Yes, extracting data with other external programs is
> easier with SQL and If I want to do that I can. I've never had the need to
> do so though as the reporting features of GnuCash gives me all the data I
> need.
>
>
>
> --
> PGP Key fingerprint = DA68 9657 0FF3 EFCB 58BD 3349 982E 6790 44C1 29D0
>
> Use saxic...@protonmail.com for end to end encrypted communication.
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Deprecation of XML file
> The *main* benefit of SQL storage is that you get immediate saves. I.e., > when you commit a transaction, it gets saved to storage immediately. So > -- no lost work. This is exactly why I *don't* use a database for storage. I often screw up entering data. I don't save until I'm happy I've done it right. With XML I can just reload the file and try again. With a database I'd have to restore the last backup, probably yesterday's, then restart GnuCash and try again losing *everything* I did today. (Yes I could manually do a backup of the sqlite file after each transaction but...). With XML I can enter a transaction, check that I've not screwed up, save the file, then move on to the next transaction, check it and save. This way If I screw up I can simply reload the XML from however many minutes ago I last saved and continue. The no-lost-work maybe fine for some|many but not for me. The only immediate advantage of a DB backend is (as far as I can see) is concurrent user access, which GnuCash doesn't do, yet, so until then I will be using the XML file storage. Yes, extracting data with other external programs is easier with SQL and If I want to do that I can. I've never had the need to do so though as the reporting features of GnuCash gives me all the data I need. -- PGP Key fingerprint = DA68 9657 0FF3 EFCB 58BD 3349 982E 6790 44C1 29D0 Use saxic...@protonmail.com for end to end encrypted communication. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Deprecation of XML file
Stefan: On 2020-09-14 12:38, Stefan Bluhm wrote: 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. I don't feel like you have summarised all the points in favour of the current XML data storage format accurately, based on the emails I saw. A few examples: 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. 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). I don't know what you are referring to by "management overhead" and "administrative overhead". A point in favour of the static XML data format is that there is no need to install a database module separately from Gnucash. I don't know what you mean by "DBI library". Maybe you mean, "SQLite is no worse than XML if we require that GnuCash includes a copy of SQLite with no extra work to install it and set it up", I could agree with that. 5) Use rsync for fast diff based backups. Should the same with an SQLite. I disagree. Diff-based backups can work differently on a text file than on binary files. An XML file saved as text is text-based, uses newlines for structure, and is basically linear. As far as I know, there is no option to save a SQLite database in text form, it is always binary and has opaque internal structure. 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) This claim does not explain what a SQLite browser can do. Also, I am not yet persuaded that a SQLite browser can do the kinds of finding and modification that XML tools can do with comparable ease. Note that in my use of the XML format, I have modified and fixed, not just "analyzed" (which I understand to be read-only). 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. The point I was trying to make about ensuring GnuCash data can persist for decades is that use of XML helps because it is more transparent (because it is text-based) and more accessible in the absence of GnuCash software and all the supporting software from the era when the file was created. By contrast, binary application-specific data formats tend to be much harder to read and understand in the absence of the supporting software. This has nothing to do with ISO standardisation of the format. It has a little to do with the breadth of tools supporting the format — the more tools for the format, the greater the chance that some will still be usable after decades. Whether the format is "well defined" today is not terribly important, because lots of information about formats gets lost in the course of years and decades. It seems clear to me that the inherent properties of XML-format data make it more robust over decades than binary app-specific formats like SQLite. I don't think its the even comparison which you portray. So, I don't think you have persuaded me that a) you have fairly summarised the points in favour of the XML format, or b) that SQLite is as good as or better for the requirements expressed in this thread. Best regards, —Jim DeLaHunt ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Deprecation of XML file
I am confused about what you are asking for. Do you want to revise the development roadmap? Are you asking in an oblique way what would they prefer you to work on? Derek said that the log term plan was already going in that direction, but they may have different stops planned on the way. David Carlson On Mon, Sep 14, 2020 at 2:39 PM Stefan Bluhm wrote: > 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" > An: "gnucash-devel" > 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@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > -- David Carlson ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Deprecation of XML file
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" An: "gnucash-devel" 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@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Deprecation of XML file
I for one use the XML back-end. --Steve On 9/13/20 11:11 PM, Stefan Bluhm wrote: > 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@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > . -- Stephen M Butler, PMP, PSM stephen.m.butle...@gmail.com kg...@arrl.net 253-350-0166 --- GnuPG Fingerprint: 8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Deprecation of XML file
Hi, On Mon, September 14, 2020 11:54 am, jean laroche wrote: > 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? The *main* benefit of SQL storage is that you get immediate saves. I.e., when you commit a transaction, it gets saved to storage immediately. So -- no lost work. Another benefit, LONG TERM, of moving to SQL is that we can improve the performance of "searches" (and EVERYTHING internally is a search). Also, theoretically, it COULD be faster because we could delay loading of data, however right now, no, it is not "faster" in that sense because we still load the full data-set into RAM when you start the program. > I know it allows simultaneous access by multiple users, but is that a > realistic usage scenario for GC? SQLite does not really allow multiple users. Moreover, supporting SQL does not immediately provide multi-user support -- there is a lot more to do to support that. So I would say that SQL is necessary for multiuser support, but not sufficient. See above on other reasons for moving to SQL. > Would it help implementing a real undo/redo mechanism? (something that I > do think is sorely missing) I don't think so. > Jean -derek -- 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
Re: [GNC-dev] Deprecation of XML file
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@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Deprecation of XML file
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
Re: [GNC-dev] Deprecation of XML file
If the backend were to be switched to SQL, perhaps there could be menu options providing the ability to import from XML and to export to XML. I believe the macOS and Windows builds include Sqlite. Chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Deprecation of XML file
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
Re: [GNC-dev] Deprecation of XML file
Stefan, just a few thoughts: Am 14.09.20 um 08:11 schrieb Stefan Bluhm: > Hello GnuCash Team, > > Is there a reason to keep supporting the XML file in future? I am happy with it since ~20 years. It can be easy analyzed by a simple grep or more advanced (XSLT, XPATH, …) commands. I can use rsync for fast diff based backups. It is a well defined format, while SQLite is not ISO complete and the other SQLs have their additional administrative overhead. > Wouldn't it be easier to force save the data to SQlite to tackle the move > from QOF? In the past have been issues special with SQLite bugs. > The benefit of point in time save (instead of transactional save) could be > achieved by working from a copy instead. I see it as one of the downsides. I save usually after finishing a logical section cotaining several transaction. In theory you could allow user defined START TRANSACTION … constructs. > Probable issue would arise from users that read the XML file directly. > > Let me know your thoughts. > > Best wishes, > > Stefan Regards Frank ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Deprecation of XML file
On 2020-09-13 23:11, Stefan Bluhm wrote: Is there a reason to keep supporting the XML file in future?… I will give you three of my reasons for being glad I can store my GnuCash data in XML form: 1. All the data is in one data file in a known location. If I want to back my bookkeeping up specially, or move it to another computer, I know exactly which file has all the data. 2. I have in the past fixed problems by operating on the XML format data. A risky move, but one which does open possibilities which the GnuCash app itself cannot offer. 3. Data longevity. My bookkeeping is data which I would like to keep meaningful and intact for decades. Even if the GnuCash app stops working, I have some confidence that XML tools will survive longer, and in any case the XML format of the data is open to tools of the future. By contrast, data in databases generally stops being usable when the database software stops running. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Deprecation of XML file
Thank you for your Feedback David. SQLite is also stored in a single file (SQLite format, not XML). So your Dropbox use case would not change. Currently, you would have to manually install the SQLite DBD to use this feature. In case of XML deprecation, the SQlite DBD should ideally be bundled with the GnuCash release then. Best wishes, Stefan Von: "David H" An: "Stefan Bluhm" CC: "gnucash-devel" Gesendet: Montag, 14. September 2020 09:10:30 Betreff: Re: [GNC-dev] Deprecation of XML file Yeah cos some of us users use the xml backend exclusively and have no intention of jumping through hoops to install and maintain some version of sql :-). In my case I run GnuCash on Ubuntu, MacOS and Windows depending on where I am and how the mood takes me. So easy to sync 1 file on Dropbox. Cheers David H. On Mon, 14 Sep 2020 at 16:18, Stefan Bluhm < [ mailto:gnucash@bluhm-de.com | gnucash@bluhm-de.com ] > wrote: 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 [ mailto:gnucash-devel@gnucash.org | gnucash-devel@gnucash.org ] [ https://lists.gnucash.org/mailman/listinfo/gnucash-devel | https://lists.gnucash.org/mailman/listinfo/gnucash-devel ] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Deprecation of XML file
Yeah cos some of us users use the xml backend exclusively and have no intention of jumping through hoops to install and maintain some version of sql :-). In my case I run GnuCash on Ubuntu, MacOS and Windows depending on where I am and how the mood takes me. So easy to sync 1 file on Dropbox. Cheers David H. On Mon, 14 Sep 2020 at 16:18, Stefan Bluhm wrote: > 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@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[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@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
