What is the intended (future?) design concerning structured type (entry.payee, amount.numbers, ...)

[mlell]

There are multiple structured objects which can be accessed using an object.attribute-syntax. For example, this query yields
four columns of which the first two and the second two are exactly equal:

select payee as n1, entry.payee as n2, number as u1, position.units.number as u2 from date > 2025-11-01 

What is the rationale between this duplication. It seems like the project can't really decide whether it wants a functional interface, were we apply a large set of functions to types to get our values (like currency(units(position))) or an object-oriented interface, where we use an attribute to get properties of objects like postings.units.currency.

Currently, both syntaxes are valid in beanquery. What is the intended direction of this?

[blais]

It's just for convenience.
The original query language was sort-of evolved quickly and not holistically, it was only for beancount.

[mlell]

Ok; I am asking for the sake of documentation (PR #263)... even if there is no pre-defined holistic concept, is there a "canonical" way in hindsight which should be used or should both ways be documented as equal alternatives?

[blais]

I don't think I've thought very hard about the design of bean-query, honestly.
Just made it up, fully expecting that at some point some of the many other local database tools would support a custom aggregator type. If they did - some of them probably do by now - bean-query could be replaced by simply implementing Amount, Posting and Inventory types in that system.