Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for multi-beancount-file setup? #3

Open
matthiasbeyer opened this issue Oct 1, 2016 · 6 comments
Open

Support for multi-beancount-file setup? #3

matthiasbeyer opened this issue Oct 1, 2016 · 6 comments

Comments

@matthiasbeyer
Copy link

@matthiasbeyer matthiasbeyer commented Oct 1, 2016

Hi,

as far as I can see, this script does not support a multi-file beancount setup.

I have accounts in one file, settings in one file, and will start to have one transaction file per month. bean-add seems to have issues with this (E.G. tab-completion for accounts does not work at all).

Any plans on improving this?

@simon-v
Copy link
Owner

@simon-v simon-v commented Oct 1, 2016

There weren't. This is a much more complicated feature than one would expect. bean-add wasn't written with this in mind, and implementing it would require some heavy rewrites.

However, there was a planned feature in bean-add that could serve as a workaround for you: writing to external files. With it, you'd make a script such as:

# Make a temporary file to work on
cat accounts.bnct options.bnct transactions.bnct > merged.bnct

# Begin editing that
bean-add merged.bnct
# Upon entering bean-add, activate the "oe" (external write) option
# New transactions are saved into "merged.bnct.new"
# Finish editing

# Append the new transactions to the main file
cat transactions.bnct merged.bnct.new > transactions.bnct.new
mv transactions.bnct.new transactions.bnct

# Clean up
rm merged.bnct merged.bnct.new

...And use that as the wrapper for your work.

Will this be adequate for your purposes?

@matthiasbeyer
Copy link
Author

@matthiasbeyer matthiasbeyer commented Oct 1, 2016

@simon-v This would be really nice, yes! I even like this approach a bit more, because it keeps bean-add simple, and simple code has less bugs! Wonderful!

@simon-v simon-v closed this in 75efbe6 Oct 3, 2016
@MisterY
Copy link

@MisterY MisterY commented May 5, 2019

I always thought that using the original system (in this case beancount) was the best option for parsing data files. Wouldn't it be better to invoke beancount and get the list of accounts? Then beancount would use whatever features (in this case include files) are currently supported.

@simon-v
Copy link
Owner

@simon-v simon-v commented May 5, 2019

Interesting. That kind of option didn't occur to me at the time. Perhaps, i'll try this, with the current system as fallback for edge cases.

@simon-v simon-v reopened this May 5, 2019
@MisterY
Copy link

@MisterY MisterY commented May 5, 2019

Thanks!
I'm generally lazy, that's why easy solutions always come to my mind before the hard ones. :))
If you can keep Beancount objects in memory during runtime, that would be pretty much it. And, with picklecache, the performance is generally not that bad.
This approach would leave you to only add functionality on top of Beancount instead of rewriting what's already there. I might also have a look once I get to the stage where I need the UI tool more frequently.
Cheers!

@simon-v
Copy link
Owner

@simon-v simon-v commented May 9, 2019

Actually, the startup delay with beancount in the middle has become quite noticeable. I have used the following command:
time echo q | bean-add journal.bnct > /dev/null

The results are:

With beancount: 0.52s user 0.06s system 98% cpu 0.585 total
Without beancount: 0.18s user 0.03s system 98% cpu 0.209 total

That's three times the wait.

With the picklecache removed or invalidated after the journal was changed, the difference is even more significant:

With beancount: 1.83s user 0.06s system 98% cpu 1.920 total
Without beancount: 0.18s user 0.02s system 98% cpu 0.208 total

And that's ten times the wait. In fact, i have a feeling that this is going to be the typical user experience (you use bean-add to, you know, add to the journal).

Everything considered, i feel it would be more reasonable to reimplement include, or run bean-query in a background subthread. Both approaches are not without their drawbacks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.