On 06/05/25 13:33, Chary Ev2geny wrote:
I may be mistaken, but it is my understanding, that at the moment
beanquery seems to be supporting 2 modes:
There aren't really two modes of operation. More simply, the dialect of
SQL that beanquery implements, the Beancount Query Language (BQL) allows
to write queries in what you call "the original mode" syntax. The query
evaluation is carried out in the same way.
The original mode.
In this mode:
FROM part is responsible for entry-level filter expressions.
You can have a WHERE clause when omitting the FROM clause to default to
the posting table or specify filtering expressions in both FROM and WHERE.
The new mode:
The "new mode" is simply writing queries in a syntax closer to standard
SQL. Treating the FROM clause more traditionally allows to query
information other than the postings table.
The JOIN feature of the SQL is not supported (yet) but for instance
postings table is already joint with the transactions table (where it is
called entry)
Technically, there is no JOIN (in the SQL sense) as there isn't a key
used to join records from two distinct tables. The postings table
returns records that include a reference to the transaction that
contains them.
In this mode all the additional perks like JOURNAL, OPEN ON, CLOSE ON,
BALANCES do not seem to be available.
Unless there is a bug somewhere, OPEN ON and CLOSE ON are supported also
when using the new syntax (although they do no always make sense).
JOURNAL and BALANCES can be thought as macros that expand to a regular
SELECT query. What do you mean when you write that the new mode does not
support them?
Q1:Is my understanding of the current state of the beanquery correct?
There isn't really a distinction between what you call the "old mode"
and the "new mode". The BQL parser simply allows to write queries with
some shortcuts.
Q2:what is the roadmap for beanquery?
There isn't a precise roadmap. Mostly because having one would imply
that there is at least the thought of resources dedicated to implement
it. The general idea is form beanquery to grow into a query tool that
can be used on more than beancount ledgers and to implement a wider
section of the SQL standard.
Will 2 modes supported going further?
Supporting the old query syntax requires compromises that I would like
to revisit at some point. Having to prefix tables in the FROM clause
with # to disambiguate between a filter expression and a table name is
the most annoying. In the future (maybe the far future) specifying a
table with the FROM clause and using WHERE for filter expression will
become mandatory. Other things will be deprecated.
Will the perks like JOURNAL, OPEN ON, CLOSE ON, BALANCES be brought in
the new mode as well?
They already are, so I don't understand this comment.
What new features are planned to be added to beanquery?
Next on my list are JOIN support (a partial implementation is already
available, but it require some more work) and support for windowed
functions, or at least a proper balance() function. Most likely other
things will be added as I need them (or as they are contributed)
What features are planned to be dropped from beanquery?
None, really. Except for dropping some unfortunate syntax that will
force users to type a few more characters when composing a query.
Cheers,
Dan
--
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/beancount/dd749f31-6aa5-459d-a80a-83878ae1f0ac%40grinta.net.
