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

[Derek Atkins]

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

> On 08/02/2012 10:54 AM, Derek Atkins wrote:
>> "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.
>
> Polling would work, yes.  It wouldn't be the most efficient system ever,
> but it would work.

Honestly I'm not worried about efficiency in a first pass.  ;)

>> 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
>> 
>
> I'd probably just wrap it in BEGIN TRANSACTION; ... COMMIT; so that it
> all happens as a single atomic transaction.
>
> Full disclaimer:  I only use DB systems that support atomic transactions
> as a given, not those that support atomic transactions as an add-on,
> optional feature of a particular set of table type(s).  :-P

GnuCash already does that.  At least it should.

My point is that it should perform a test at the onset to see if the
data changed before the user starts editing it in the UI.  I.e., when
the user starts to make a change to an existing transaction the UI
should query the backend to see if the data had changed and lock the
transaction (row-locking, if possible, theoretically).

The point is to try to lock the rows involved so that multiple people
don't step on each other.  Yes, you get atomicity with the BEGIN/END,
but that's not the issue.  The issue is the user in the UI.  You want to
give Alice some visual cue that Bob is trying to edit the same
transaction.  (Note that I'm using the same word to mean both a GnuCash
transaction and a DB transaction.  I'm sure it's confusing).

Honestly, this discussion belongs on the gnucash-devel mailing list.

>>> 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.
>
> It's not about trust, not at all.  It's more the fact that the system
> scares people.  I think it's the fact that it is an accounting system
> more than anything else.  Personally, I have found GC to be a very nice,
> easy to use system compared to other things that I have tried to use in
> the past.  It's a pleasure.

Thank you. :)

> But for others, they want and/or need something that simply doesn't show
> them the low-level details.  Instead, they just want to see what they
> need to see to get the data input and the job done.

I guess it depends on the definition of the job and what it means to
"get it done".

> I have one person that is fully comfortable with GC, used it to manage
> his personal finances.  (He doesn't anymore, but that's because he
> didn't backup the GC data file and the computer was stolen...)  He would
> be able to use the system, save for the fact that he currently doesn't
> have a connection to the network it is running on.  In a worst-case
> scenario where he needed to take things over, he could through an SSH
> tunnel to get to the database server, though.

*nods*

> 	--- 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