Way to identify a single transaction inside a plugin?

[Matthias Beyer]

Hi,

first of all: Thanks for writing beancount and fava. I'm currently not using it
as I have no time to do the switch (from Skrooge), though I really want to
switch as soon as I have some time.

I have a question related to plugins: Is there a way for a plugin to uniquely
identify a transaction? Like a UUID, hash or something similar for each
transaction, so I can identify transactions in some way?

--
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.

[Martin Blais]

As Filippo suggests, each transaction has a unique hash you can derive from it, but I'd like to hear more about your use case: I was going to suggest that if you want the user to be able to tag some particular transactions with a id, you can use metadata, tags or links for that. So when you say "so I can identify transactions in some way" what do you mean exactly? What's the task you're trying to accomplish?

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/20160527134150.GA20550%40yuu.
For more options, visit https://groups.google.com/d/optout.

[Matthias Beyer]

On 28-05-2016 17:23:55, Martin Blais wrote:
> As Filippo suggests, each transaction has a unique hash you can derive from
> it, but I'd like to hear more about your use case: I was going to suggest
> that if you want the user to be able to tag some particular transactions
> with a id, you can use metadata, tags or links for that. So when you say
> "so I can identify transactions in some way" what do you mean exactly?
> What's the task you're trying to accomplish?

So here's my use case (plus a bit of story):

I write a commandline PIM suite[0]. I "write" it by re-using tools, collecting
their data (creating references to the data, not duplicating it), to be able to
refer from data of one tool to data of another tool:

Beancount Transaction ABC <<-- some kind of ref -->> Taskwarrior task XYZ

The references are stored in a "store" (not in the data of the respective tool
itself).

I collect this data by using the APIs of the tooks (taskwarrior -> hook api,
beancount -> plugin API, etc.)

(sidenote: This is also why I choose beancount and not ledger-cli or hledger
- because they do not have an API.
I choose beancount because of available features (fava beeing one big
reason))

What I plan on doing: My tool stores hashes to each transaction. The user can
use this hashes to "link" the transactions.
I will provide scripts and tooling to re-find the transactions.

One problem I haven't figured out yet: Does the hash of a transaction change if
the transaction

* gets moved to another file/location in a file
* gets changes (naming of the involved accounts, date, tags, other data)

? This would be kind of critical, as this would result in dangling "pointers"
(hashes) in my database.
I'm rather sure that the listed changes result in a change of the hash, don't
they? I'm not sure how to wrap around these issues.

It is no option for me that the user has to put in the required metadata to
generate references, as this would

* cause users to re-write large parts of their beancount data
* add noise in the beancount data which shouldn't be there

Besides the above: The tool I'm writing is far from usable, but I make steady
progress. I plan on implementing all aspects of personal information management
and I target plain-text and console only.

Feel free to ask me questions.

[0]: https://github.com/matthiasbeyer/imag

[Martin Blais]

No.

 

    * gets changes (naming of the involved accounts, date, tags, other data)

Yes.

? This would be kind of critical, as this would result in dangling "pointers"
(hashes) in my database.
I'm rather sure that the listed changes result in a change of the hash, don't
they? I'm not sure how to wrap around these issues.

Based on your application, I think what you should do is decide which subset of the fields matter and derive your own unique hash from the Transaction object.

FYI the original hashing code is located here:

https://bitbucket.org/blais/beancount/src/7250b43b115603f5cbcc2088b2d124034ceaf766/src/python/beancount/core/compare.py?at=default&fileviewer=file-view-default#compare.py-63

 

It is no option for me that the user has to put in the required metadata to
generate references, as this would

    * cause users to re-write large parts of their beancount data
    * add noise in the beancount data which shouldn't be there

Besides the above: The tool I'm writing is far from usable, but I make steady
progress. I plan on implementing all aspects of personal information management
and I target plain-text and console only.

Feel free to ask me questions.

[0]: https://github.com/matthiasbeyer/imag

--
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/20160528225244.GB26461%40yuu.

[Matthias Beyer]

On 01-06-2016 22:34:05, Martin Blais wrote:
> > One problem I haven't figured out yet: Does the hash of a transaction
> > change if
> > the transaction
> > * gets moved to another file/location in a file
>
> No.
>
> > * gets changes (naming of the involved accounts, date, tags, other
> > data)
>
> Yes.
>
> ? This would be kind of critical, as this would result in dangling
> > "pointers"
> > (hashes) in my database.
> > I'm rather sure that the listed changes result in a change of the hash,
> > don't
> > they? I'm not sure how to wrap around these issues.
> >
>
> Based on your application, I think what you should do is decide which
> subset of the fields matter and derive your own unique hash from the
> Transaction object.
>
> FYI the original hashing code is located here:
> https://bitbucket.org/blais/beancount/src/7250b43b115603f5cbcc2088b2d124034ceaf766/src/python/beancount/core/compare.py?at=default&fileviewer=file-view-default#compare.py-63

This sounds like a solution for me, thanks!