warlord at MIT.EDU
Fri Aug 14 09:00:43 EDT 2009
Please remember to CC gnucash-devel on all replies using your mailer's
Reply-To-List or Reply-All functionality.
Vladimir Bashkirtsev <vladimir at bashkirtsev.com> writes:
> Perhaps I need to check ascertain amount of work involved. There's two
> approaches we can take: first one is using timestamps and re-reading
> data if change happened. Second one is to get data straight out of DB
> each time it is needed and use DB transactions (if available). First
> approach most likely will be prone to data corruption and re-reading
> whole lot will slow things right down. Second approach looks like more
> appropriate but most likely it will require good amount of work as it
> is quite different to current architecture. Can you give your opinion
> about how hard it would be to implement second approach? How hard it
> is to get GnuCash not to use data from memory but use it directly from
The hardest part is figuring out "what changed". Ideally we'd have an
audit log in the database, which would effectively mimic the .log files
for XML. Every operation would get logged in the DB both for potential
undo and also for later auditing.
It would be nice if there were some way to "notify" clients that there's
a change to the DB so it knows it should reload. However most DBs dont
have that, so we'd need to do it manually by, say, an epoch number for
the database. Everytime the db is updated you increase the epoch.
Another way you could do this would be an autoincrement in the 'audit
log' and thereby use your audit log id number as your epoch.
Really, tho, this is just a cache coherency problem, which has been
solved many times in many ways.
However, changing the architecture of GnuCash to be a pure DB app would
entail rewriting MOST of the engine. I wouldn't recommend going that
route in the short term.
> Of course I can just read the source but it would take sometime and
> your opinion can get me to make a decision to do it or not a bit
You should still read the source. :)
> Derek Atkins wrote:
>> Vladimir Bashkirtsev <vladimir at bashkirtsev.com> writes:
>>> I was testing latest development version with MySQL backend and in
>>> general I was satisfied with the results. Great piece of software!
>>> Now here the scenario I want to happen: I have PHP scripts which deal
>>> with GnuCash data in MySQL DB. It is not a problem to read and show
>>> account records from MySQL. But PHP scripts should be able to post
>>> invoices back to GnuCash DB. This side of business is working well too
>>> but if I have GnuCash open and connected to the same MySQL DB no
>>> update in GnuCash happens. I've being looking for something what may
>>> get GnuCash to re-read records but I cannot find anything like
>>> it. Does MySQL backend has something like this? Perhaps having "last
>>> modified" in DB record would be good and GnuCash should check it
>>> periodically. Or the best way is to not to cache anything in memory
>>> and use MySQL for each single operation. Or I just dreaming? :)
>>> Generally it comes to concurrent use of the same DB by two separate
>>> GnuCash processes and how they get in sync. Without syncing use of DB
>>> does not gain much in relation to XML file.
>> This would be "multi-user support" which is not supported at this time.
>> As Phil says, it's also not on the current path so unless some developer
>> comes in and offers to implement multi-user I don't see this happening
>> any time soon.
>>> PS: I have read warnings about modification of the data by something
>>> but GnuCash. Still it appears to be the best way to resolve my
>>> gnucash-devel mailing list
>>> gnucash-devel at gnucash.org
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord at MIT.EDU PGP key available
More information about the gnucash-devel