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

vision/direction: hledger could accept a directory full of journal files, rather than a single journal file #116

Closed
tphyahoo opened this issue May 30, 2013 · 4 comments
Labels
A-WISH Some kind of improvement request, hare-brained proposal, or plea. journal The journal file format, and its features.

Comments

@tphyahoo
Copy link

This is a wish/suggestion which emerged from conversation with Mike Klein / JavaSucksMan.

Note: this idea can be considered completely orthogonal to hledger as presently constituted. All it requires is translating the proposed new repo format to the file. Of course, if hledger community falls in love with the idea, the mainline code could use a directory rather than a file for state.

Anyway, the idea: Rather than keep the state in a single file (~/.hledger.journal), hledger could keep state in a directory, which contains multiple files in the journal format. Possibly 1 file per transaction, but perhaps transaction batches could be allowed as well. To be determined.

The advantage of doing things this way is that it opens the door to using a version control system to add another layer of control / auditing functionality over who is doing what with the ledger. Down the line (waving hands here) you could even have journal entries linking binary files (also in repo) such as images of scanned receipts, or audio files with verbal notes like "Google Glass, Wake HLedger: Record found $20 on the sidewalk."

Integration of accounting assets as binary files is down the line and obviously a lot of work, but I think doing things repo style with multiple files could yield increased functionality with not that much work.

Mostly it just requires a function to translate a directory full of transactions into the ledger format at startup time. Repo integration would be orthogonal to hledger functionality. You would just put your directory in github and use the nice tools there.

Of course, you could also just keep a single file in a repo but
a -- diffs will be messier
b -- one file per transaction allows pessimistic rather than optimistic transactions if there are multiple people editing transactions. You would have an audit trail per file/transaction then.

@simonmichael
Copy link
Owner

The include directive means you can simulate that now, eg having the
main file include all the others (explicitly).

Automatically including all files in the directory sounds quite
pleasant to use. Wouldn't you or hledger have to be a bit more careful
to avoid wrong reports due to including undesirable files, like editor
backups ?

@tphyahoo
Copy link
Author

cat *.journal-transaction > .hledger.journal

I think that's all you need for version 1.

Takes care of the editor backup problem anyway.

"Boring" files in your favorite version controlling systems do most of the rest of what you need.

Version 2 would be a bit smarter. Instead of cat, use a haskell program that loads each file and does map smartThing before outputting, where smartThing would (for starters) do parsing and die if bad format.

Now you can have repo hooks that won't commit if some .journal-transaction file has a bad format.

@simonmichael
Copy link
Owner

Supporting wild cards in the include directive (as ledger does) would
be a good step here.

@simonmichael simonmichael added the journal The journal file format, and its features. label Nov 15, 2015
@simonmichael
Copy link
Owner

Doing some bugtracker cleanup, closing some old wishlist issues. These can be reopened if someone gets around to working on them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-WISH Some kind of improvement request, hare-brained proposal, or plea. journal The journal file format, and its features.
Projects
None yet
Development

No branches or pull requests

2 participants