Any way to "thread" transaction history?

[ericoe]

I love this package Jack. 3 quick questions:

1. I'm doing this for my update. Cards.update( {_id: id}, {$set: card}, {tx: true, description:"funky edit", context: {deckId:"abc", cardId:"123"}} ); The context gets saved, but the "description" does not. Any way to change the description?
2. In my model, I'm working with metaphorical "documents". The multi undo/redo is great. But when the user switches from "doc" A to "doc" B... clicking undo in doc B starts reverting document A. Any way to filter transactions by "context" with the API or should I include your sources in my project and filter what the server publishes?
3. If I do #2, I can fix #1. Will the undo/redo still "work"? All the tx records for a "mongo document" would still be processed sequentially. It would be really cool if .undo/redo() could take a parameter for "threadId" or "contextId". :)

Thank you!

[JackAdams]

@ericoe. So sorry I didn't reply here earlier:

1. The description you refer to would be the text that goes on the undo/redo buttons, right? context is a special-cased field, which is why it gets saved, but other arbitrary fields are not saved anywhere. To alter the description, use tx.start("funky edit"); Cards.update( ... ); tx.commit();.
2. This is do-able using the context, but not easily -- you'd need to write your own undo ui/logic. You can target specific transactions for undo/redo by writing tx.undo(transaction_id) or tx.redo(transaction_id). To get the transaction_id, you'd have to filter the available transactions by something you've stored in the context of the transaction documents.
3. This is possible (I can think of a way), but it's not implemented yet. Will leave this issue open to remind myself to do it.

[ericoe]

1. Yes. Exactly. And I was thinking start/commit was overkill w/o looking at what was going on under the covers already.

2 & 3. Got it. Thanks. I'll play around with undo via tx ID and a custom filter and see what happens. :)

[JackAdams]

For 1., I agree that it's overkill. I'm thinking of introducing a description field for single-action transactions that auto-commit. Makes it quicker than wrapping the single mutator command in a start-commit block. But it could also lead to confusion, as it would be ignored for a multi-action transaction.