[ale] [Way OT] GnuCash (Was: Re: GnuCash (Was: Re: [OT] Home PBX?))

Derek Atkins warlord at MIT.EDU
Thu Aug 2 10:54:29 EDT 2012


"mike at trausch.us" <mike at trausch.us> writes:

> On 08/01/2012 12:06 PM, Derek Atkins wrote:
>> Patches are always welcome!  :)
>
> Of course!
>
> That said, given your description, the only reasonable method I could
> see would be to support _only_ PostgreSQL, since that has a
> notifications mechanism that could support the invalidation of GC's
> internal cache.  As far as I'm aware, no other database system provides
> such a mechanism (other than perhaps Oracle).  It would also require
> that GC's database driver listen for notifies.

Not necessarily.  You could also implement it as a lazy evaluation.  You
don't need the client to update in real time, the client can just do a
data check and refresh when it needs to, and just verify that the data
is still current before allowing the user to edit.

For example, when calling xaccTransBeginEdit() to begin editing a
transaction it could theoretically:

1) check to make sure the txn is current, and
2) lock the transaction in the database

> The only other fix I could think of based on what you said would be to
> ensure that the application never makes the assumption that data resides
> in core, and that would likely make it quite a bit slower.  Or it could
> be done such that it uses something like memcached and a cache manager
> that sits between the database itself and memcached and knows how to
> invalidate memcached's cache (assuming, that is, that such a thing is
> indeed possible, though I can't see any reason why it wouldn't be).

That's another option, but not necessary.  See above.  There are ways to
do data refreshes without requiring an asynchronous notification.

> What I have been doing is, for now, using GC as our authoritative set of
> books, entering data based on events that happen.  Where I would like to
> wind up is with a single system (or a single integrated system of
> systems) that does the same thing, but with the effect of lightening my
> administrative overhead and gaining the capability of delegation.  I
> could technically delegate to a bookkeeper, but I haven't the budget for
> one at the moment.  CPAs, when I need them, tend to break any budget
> that might exist for a regular bookkeeper.  :-)

But you don't trust multiple people to have full access to your books?
You CAN have multiple people entering data.  Just not simultaneously.

> 	--- Mike

-derek

-- 
       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 Ale mailing list