Replies: 2 comments 9 replies
-
|
Thanks so much for sharing, I am very excited about
If it's Git vs a million files, then I think Git could be much faster. If it's Git vs a couple of bigger files, then I think the 20% performance advantage are due to compression. From what I can tell, Git is used for snapshotting and each change becomes a commit. For reading values, When looking at the linked code, I thought that maybe one would even want to support When opening the repository, and it's from a well-known location, I'd recommend using Otherwise I think it's pretty optimal, but depending on how long parsing transaction files takes, one might consider parallelising that. That's all my thoughts on the Git part :)! |
Beta Was this translation helpful? Give feedback.
-
Exactly! There are multiple aspects on that:
About how items / money move from one account to another The first principle is that there must be at least two accounts with value (postings) in the transaction, and the sum of postings must be zero. This is the same principle as with normal double-entry bookkeeping with debit and credit accounts, but with plain text accounting system that's denoted by sign (+/-) for accounts. Here are two examples about how items or money could move around:
That's precious offering! I will keep it in mind when I'm a bit of a pickle with git! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! I found both examples very interesting! With the one about filter definition I wondered if it could just read the filter from a file. And one more thought I had: What if there are several partitions, like multiple stores of a chain, and these should operate locally but submit their transactions at the end of each day. They shouldn't, however, have full access to all the companies transactions and accounts. This would mean there would have to be 'links' to accounts they don't have, has they would still have to denote transactions from or to accounts they don't own. For them, these would be more like proxies as they only have transactions that they are involved in. This isn't a feature request :D, just a thought. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, the idea of file based filter definition is good, I have to think if there would be feasible way to have it with variables (e.g. for timestamps). For the second one, that's really interesting question and thought, and my first impression was that it's not possible, and would be quite tricky to implement. But there is no need to file a feature request ;) This will be quite long, but there is more git than tackler on this one - the spoiler is Establish Acme Inc. Headquarters cd tackler-ng
mkdir -p tmp/acme-inc
cd tmp/acme-inc
git init --bare acme-hq.git
git clone acme-hq.git/
cd acme-hq
git commit -m init --allow-empty
git push
cd ..Acme Inc. Store A # inside 'tackler-ng/tmp/acme-inc'
git init --bare acme-store-A.git
git clone acme-store-A.git/
cd acme-store-A
git commit -m init --allow-empty
git push
cd ..Acme Inc Store B # inside 'tackler-ng/tmp/acme-inc'
git init --bare acme-store-B.git/
git clone acme-store-B.git/
cd acme-store-B
git commit -m init --allow-empty
git push
cd ..Sales event on Store A! # inside 'tackler-ng/tmp/acme-inc'
cd acme-store-A
mkdir -p txns/store-a
cat << EOF >> txns/store-a/txns-001.txn
2024-12-17 'store a txn
Assets:Cashier 42 €
Warehouse:Acmerator -1 Unit @ 42 €
EOF
git add .
git commit -m 'store-a'
git push
cd ..Sales event on Store B! # inside 'tackler-ng/tmp/acme-inc'
cd acme-store-B
mkdir -p txns/store-b
cp ../acme-store-A/txns/store-a/txns-001.txn txns/store-b/
sed -i 's/store a/store b/' txns/store-b/txns-001.txn
git add .
git commit -m 'store b'
git push
cd ..Busy day at Accounting department of Acme Inc Headquarters # inside 'tackler-ng/tmp/acme-inc'
cd acme-hq
git remote add store-a ../acme-store-A.git
git remote add store-b ../acme-store-B.git
git remote update -p
git merge --allow-unrelated-histories store-a/main
git merge --allow-unrelated-histories store-b/main
find txns/
cd ..In the meanwhile Store B has been really busy # inside 'tackler-ng/tmp/acme-inc'
cd acme-store-B
cp txns/store-b/txns-001.txn txns/store-b/txns-002.txn
cp txns/store-b/txns-001.txn txns/store-b/txns-003.txn
git add .
git commit -m 'store b'
git push
cd ..Time to report numbers of holiday sales push # inside 'tackler-ng/tmp/acme-inc'
cd acme-hq
git remote update -p
git merge --allow-unrelated-histories store-b/main
cd ..Acme Inc HQ's reporting definition, this makes it possible to switch between working copy and repository with [kernel]
strict = false
audit = { mode = false, hash = "SHA-256" }
timestamp = { default-time = 00:00:00, timezone = { name = "UTC" } }
[kernel.input]
storage = "git"
fs = { dir = "acme-hq/txns", suffix = "txn" }
git = { repository = "acme-hq/.git", dir = "txns", ref = "main", suffix = "txn" }
[transaction]
accounts = { path = "none" }
commodities = { path = "none" }
tags = { path = "none" }
### Report Configuration
[report]
report-timezone = "UTC"
scale = { min = 2, max = 4 }
accounts = [ "^Assets:", "^Warehouse:" ]
targets = [ "balance", "register" ]
balance = { title = "Balance Report" }
balance-group = { title = "Balance Group Report", group-by = "month" }
register = { title = "Register Report" }
### Export Configuration
[export]
targets = [ ]
equity = { equity-account = "Equity:Balance" }# inside 'tackler-ng/tmp/acme-inc'
../../target/release/tackler --config acme.tomlAnd that's the beauty of these simple concepts: Each transaction is valid as single unit, so stores can run their own reports, and at the same time HQ can run reports over all transactions. And git (and Gix!) makes all of this possible! P.S. For this example all stores use the same Chart of Accounts, but it doesn't have to be so, everything would work similarly, even if stores would use e.g. own sub-accounts for warehouse balances. |
Beta Was this translation helpful? Give feedback.
-
|
This is great! Git is used to bring together the independent views of each store, and if these stores use the same account names, HQ would be able to aggregate them naturally. Of course, nothing would prevent them from homing in on individual stores to get their view, or from keeping all account names separate, but aggregating sub-accounts or what not (I really have no clue what I am talking about 😅). Now I am even more excited! |
Beta Was this translation helpful? Give feedback.
-
|
Here is balance report so that the account structure is And these account structures could be enforced store by store basis, as there is that option for strict account name checking with the config (not activated in the example). Here we have recursive balance view of that Warehouse account tree. The left most value is sum of the leaf account alone, the right most value is sum of that account and all of its children. So from here we can see that Warehouse at Store B is down -3 units and Warehouse at Store A is -1 Units, total 4 units sold. P.S. Mandatory Git related thing: At some point JGit people were planning to have Raft based multi master backend for JGit (Git Ketch): https://projects.eclipse.org/projects/technology.jgit/releases/4.3/review (Disclaimer: Tackler is my hobby project and I'm not commercially building any such system, but even then, multi master Ketch based backend would be really cool) |
Beta Was this translation helpful? Give feedback.
-
|
This is related to idea on Gitoxide Readme: Spin-Offs: Time Tracker This is real time tracker entry for Tackler-NG project: the It's using seconds as based unit for time tracking and converting those to hours with ratio of 0.00027778. The entry is generated with separate tool. The tool is committing directly to Git repository, but it's currently Scala+JGIt. I'm planning to port it to Rust+Gix eventually. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks so much for pointing this out! Now that I learned about tackler I definitely thought about integrating with it with such a timetracking tool, but I also realise that it's very possible and just as reasonable to do time-tracking directly in tackler. I am definitely looking forward to the port! Independently of that, I recommend also taking a look at |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, that's nice tip, as good datetime library with included support for TZ would be really nice. |
Beta Was this translation helpful? Give feedback.
-
Hello Gitoxide project,
I have ported a git based application from Scala to Rust, and Gix has played a major role in making that possible!
Tackler-ng is bookkeeping engine and tool with native GIT SCM support for plain text accounting. It can read transaction data as text files either from the disk, or directly from bare git repository.
Part of the test suite are tests with large amount of transactions, up to 1 million transaction (files). In these tests git repository access (by Gix) is about 20% faster than reading from plain disk!
The first priority has been to reach feature parity with the old code base so this is totally un-optimized code, but the code to access repository is here (if it's helpful to somebody):
https://github.com/e257-fi/tackler-ng/blob/0fb1ee326338cf35ea8e7994b8d228766ce4724d/tackler-core/src/parser/tackler_txns.rs#L59
Thank you for making Gitoxide (and rusty tackler possible) - it has been fun journey (starting from Gix 0.35.0)!
Beta Was this translation helpful? Give feedback.
All reactions