Add-on: io.jmix.aitools 3.0.1
What happens
The assistant cannot answer a question about a dynamic attribute, and it fails silently — it says nothing was found rather than that it cannot look.
That is the part worth fixing first. A reviewer of our application concluded the model was too weak and asked us to retry on a larger one; a larger model fails identically, because the information never reaches it.
Evidence
Document implements Categorized; a "Contract" category defines counterparty, amount, validUntil, status. Asked for all documents from counterparty that exists for sure, the assistant returned nothing and never issued a query that could have found them.
jmix-aitools-3.0.1.jar contains zero references to dynattr or CategoryAttribute: the described model is built from JPA metadata, and the executor's queries cannot reach dynat_CategoryAttributeValue in any case.
Ask
- Describe the dynamic attributes of an entity that is already in the described model — code, name, type, and enumeration values — via DynAttrMetadata#getAttributes / #getAttributeByCode.
- Allow filtering by them. Since JPQL cannot express d.+counterparty, the condition becomes a correlated subquery:
select d from dms_Document d
where exists (
select v from dynat_CategoryAttributeValue v
where v.entity.entityId = d.id
and v.code = :code
and v.stringValue = :value
)
A dedicated tool is the smaller change; rewriting inside the existing JPQL path is the more general one.
One design note
Keep the query rooted in the constrained entity. Rooted at dynat_CategoryAttributeValue and mapped back, it returns documents the caller may not read; rooted at Document with an EXISTS, it does not. The inverted form is the easier one to write, so it is worth saying in the API docs.
For the same reason, widening include-entities to dynat_* is not a substitute: the executor's loadValues path does not apply @PredicateRowLevelPolicy, so entities protected only by a predicate come back unfiltered there.
Meanwhile
I've added a project-level JmixAiTool that queries from Document and narrows by attribute value, and did not widen the allow-list. Every application using dynamic attributes will write the same thing.
Add-on: io.jmix.aitools 3.0.1
What happens
The assistant cannot answer a question about a dynamic attribute, and it fails silently — it says nothing was found rather than that it cannot look.
That is the part worth fixing first. A reviewer of our application concluded the model was too weak and asked us to retry on a larger one; a larger model fails identically, because the information never reaches it.
Evidence
Document implements Categorized; a "Contract" category defines counterparty, amount, validUntil, status. Asked for all documents from counterparty that exists for sure, the assistant returned nothing and never issued a query that could have found them.
jmix-aitools-3.0.1.jar contains zero references to dynattr or CategoryAttribute: the described model is built from JPA metadata, and the executor's queries cannot reach dynat_CategoryAttributeValue in any case.
Ask
One design note
Keep the query rooted in the constrained entity. Rooted at dynat_CategoryAttributeValue and mapped back, it returns documents the caller may not read; rooted at Document with an EXISTS, it does not. The inverted form is the easier one to write, so it is worth saying in the API docs.
For the same reason, widening include-entities to dynat_* is not a substitute: the executor's loadValues path does not apply @PredicateRowLevelPolicy, so entities protected only by a predicate come back unfiltered there.
Meanwhile
I've added a project-level JmixAiTool that queries from Document and narrows by attribute value, and did not widen the allow-list. Every application using dynamic attributes will write the same thing.