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
