On Sat, 14 Aug 1999 14:17:16 EDT, the world broke into rejoicing as
Per Bojsen <[EMAIL PROTECTED]> said:
> *** Regarding My Understanding Of The Engine; [EMAIL PROTECTED] adds
:
> cbbrowne> Am I way off here? Or does this sound like the right
> cbbrowne> direction?
>
> I can comment on the best method to use in Scheme/Guile but I can at
> least give you an idea of how I approached essentially the same
> problem using the perl interface to the engine.
> the edit.
[elided details]
> So to summarize the sequence is:
>
> 1) Create the accounts.
> 2) For each transaction
> a) Create the splits.
> b) Create the transaction.
> c) Attach the splits.
> d) Commit the transaction.
That agrees with what I'm trying to do, for the most part.
It's not clear to me that it is necessary to do the "commits" when
doing this stuff en mase; I'll see how that goes.
> I ran the perl script outside Gnucash so I didn't have to worry about
> somebody modifying the database underneath the script the way Rob was
> talking about. I guess in that case the hole is the timing of
> xaccAccountInsertSplit() and the fact that you can't insert all splits
> simultaneously in an atomic operation (I think. Can you?).
>
> Is there any way to lock the transaction database while you're
> modifying it?
It looks like there are two relevant "locks":
a) The lock associated with the data file. When you have myfile.xac open,
another instance of GnuCash can't mess with it, but rather aborts if it finds
myfile.xac.LCK.
b) In memory, the notion of "locking" everything else whilst the import
is taking place.
As far as I can tell, there's not a separate thread of execution; once
my Guile code gets running, it appears to have control over the whole
system until it's done. (The keyboard and widgets "block")
That goes to say that all the locking that is likely necessary is already
in place.
It *appears* that invoking a Guile function is an atomic operation from
the perspective of the GUI; that's pretty adequate to keep this safe.
My approach is something like:
1) Read in QIF file, parse, and put into QIF-oriented data structures.
- Works quite well, at least for accounts that "look like chequing."
2) Check categories against GnuCash's.
- Works quite well, and a Cool Thing that could become very powerful.
3) Create accounts as needed.
- To Do. (Not really started.)
I'd like for this to be an interactive process.
This is actually *very* necessary; the one piece of data that is at
this point quite missing is the "main account." A QIF file comes from
an account, and that account becomes the implicit destination of each
and every transaction in the .QIF file. Unfortuantely, the *name*
of the account is not included in the file anywhere.
What I need is some way of getting that as input from some other source.
Right now, it's being "hacked" manually in Scheme which is not a
deployable answer.
4) Create a mapping of QIF categories to GnuCash accounts.
- To Do. (Parts of this are in 2, byt I'll claim it's not started.)
5) Map the QIF data structures to GnuCash equivalents that will be the
"neutral" data format.
- Partly done; this is essentially what I've been asking questions about
this week.
6) Run through the data structures created in 5), creating Splits and
Transactions, and linking them to Accounts.
- Started; some conflation of 5) and 6) that I need to fix.
7) It's all loaded; be happy.
--
Dijkstra probably hates me
(Linus Torvalds, in kernel/sched.c)
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
