I am still thinking a lot about this idea of a general query language for transactions. Not clear to me if the best abstraction is relational one (tables, SQL like) or a graph based, more like SPARQL or https://www.youtube.com/watch?v=QFaH6IvbPiw approach.
I remember that I read something in the past about a general mapping from transactions to graph. []s Alexandre On Sep 29, 2014, at 5:02 AM, Martin Blais <[email protected]> wrote: Hi, I've been doing some thinking about creating a query language for Beancount for a while, but until a few days ago I was left profoundly unsatisfied with the design I had in mind, but I think I've finally nailed down an idea that would allow me to remove all report types (i.e., no more "balances" (Ledger: bal), no more "journal" (Ledger: register)): by combining filtering of transactions with filtering of postings, as two separate clauses, in a SQL-like syntax where you get to specify the desired output columns and inventory aggregations. The target of the FROM clause is not a table name, but a set of filters applied to full transactions, and the WHERE clause applies to postings. The ideas are a little bit fresh, so this proposal might feel a bit "stream of consciousness" and needs a bit more polishing. See the "Two-Phase Filtering" section of this doc: https://docs.google.com/document/d/1d88MkHqxiVdF8XSQBT1QQpOKEOt6OC1P9ZoF3u86DwI/edit?usp=sharing I'd love some feedback and your thoughts (as always you can comment on the doc directly). If this works as I imagine it would, I would remove support for all other report types, or perhaps create aliases for them to canned select queries. -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
