The fix is for LoadManyRequest to detect when a MapKey is on the collection
and include that in the lazy loading query (to avoid the N queries invoked)
Originally the API took explicit transactions but then the API changed
toward query.usingTransaction(), which means the SpiQuery holds the
explicit transaction.
This change is to update the SpiEbeanServer API to reflect that it can get
explicit transaction from SpiQuery.transaction() rather than pass transaction
around.
Doing this also identified a small bug where L2 cache could be hit when it should
not after there is some update on the transaction (hence the adjustment to the
test TestBeanCache missCount)
The filterMany( <string expressions> ) uses the language parser which
ultimately will we probably remove in ebean 15.x
Code can migrate to filterManyRaw() instead or better yet change to
use the improved query beans filterMany( <closure> ) option that will
be included in this same ebean release.
Fix for the case where the filterMany is not executed on a separate
query but instead part of the origin query.
The fix is to use the appropriate DeployParser and also fix the path
alias like ${} -> ${contacts}
Fix for the case where the filterMany is not executed on a separate
query but instead part of the origin query.
The fix is to use the appropriate DeployParser and also fix the path
alias like ${} -> ${contacts}
Query beans also generate a "Assoc" query bean that is used
for the relationships. Previously these were generated into a
.query.assoc package and with this they are generated as an
inner class of the query bean.
This then allows the change where an additional filterMany()
is generated on the "Assoc" bean that takes a closure. This
simplifies the use of query beans for filterMany.
This change to the generated query beans needs a change to the
ebean-agent enhancement.
- Don't cache ebean compiled query plan when InTuples goes into literal mode
- Postgres maxInBinding = 32_000;
- SQLite maxInBinding = 800;
- Note that not caching the compiled query plan means that metrics visitor isn't
going to see it, we lose collection of that query execution metric. We might
need a plan to fix this later.
So as to not exceed the limit on bind values, the InTuples expression can
go into literal mode where it uses literal values for supported types -
Numbers, Strings, UUID, and LocalDate.
The MultiValue binding that we use for Postgres, Yugabyte etc was lost with
the changes in #3133 and this puts that back.
We desire to use Postgres ANY Array binding for these cases.
Rob Bygrave