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.
When we have a read replica with potential for replication lag, and config a read only DataSource to use that read replica, by default a query executed without a current transaction will use the read replica.
We specify usingMaster() when we explicitly want to execute a query and use the master data source.
Unfortunately we have order() and orderBy() methods which do the
same thing. I have decided to deprecate the order() ones in
favour of the orderBy() methods so that ultimately we will end
up with less methods and I think orderBy() is the correct choice.
Apologies for the migration pain here.
Typically migrate to `.setBeanCacheMode(CacheMode.PUT)` or `.setBeanCacheMode(CacheMode.OFF)`
```java
/**
* Deprecated - migrate to use setBeanCacheMode(CacheMode.PUT) or other CacheMode.
* <p>
* When set to true all the beans from this query are loaded into the bean cache.
*/
@Deprecated
Query<T> setLoadBeanCache(boolean loadBeanCache);
```
Should no longer be used / set to true.
```java
/**
* Deprecated - look to have explicit order by. Sets the default orderById setting for queries.
*/
@Deprecated
public void setDefaultOrderById(boolean defaultOrderById) {
this.defaultOrderById = defaultOrderById;
}
```
Removing all the deprecated query methods from ExtendedServer. Migrate to passing
the explicit transaction to the query using query.usingTransaction() instead.
- captureMicros is the time taken to capture the specific query plan
- whenCaptured is the time when the bind values were taken
The DefaultQueryPlanListener logging will include these in the
output it logs
java.util.ConcurrentModificationException
at java.base/java.util.HashMap$HashIterator.nextNode(HashMap.java:1493)
at java.base/java.util.HashMap$KeyIterator.next(HashMap.java:1516)
at java.base/java.util.AbstractCollection.toString(AbstractCollection.java:472)
at java.base/java.lang.String.valueOf(String.java:2951)
at io.ebeaninternal.server.core.DefaultBeanLoader.loadBean(DefaultBeanLoader.java:134)
at io.ebeaninternal.server.core.DefaultServer.loadBean(DefaultServer.java:475)
at io.ebeaninternal.server.loadcontext.DLoadBeanContext$LoadBuffer.loadBean(DLoadBeanContext.java:217)
at io.ebean.bean.InterceptReadWrite.loadBeanInternal(InterceptReadWrite.java:742)
at io.ebean.bean.InterceptReadWrite.loadBean(InterceptReadWrite.java:724)
at io.ebean.bean.InterceptReadWrite.preGetter(InterceptReadWrite.java:837)
at ...
The issue being that shutdown() // with no args was
not calling ShutdownManager.unregisterDatabase(this)
noting that shutdown(boolean, boolean) did.
This change merges the old shutdownInternal(boolean, boolean)
method into shutdown(boolean, boolean) and simplifies
shutdown() to just call shutdown(boolean, boolean).
In DatabaseConfig.isAutoLoadModuleInfo() it only used the querybean generated class registration is classes.isEmpty(). Changing this so that it only uses the loadModuleInfo flag.
This means, unless loadModuleInfo is set to false the classes that register with ebean will be a combination of both the explicitly registered ones plus the classes from the querybean generated EbeanEntityRegister.
In addition, this changes the classes from List to Set.
The history behind this is that originally there was a "profileId" concept where that was a int value that could be used as an "id" for a transactional method that we wanted to profile.
That went away and then the idea was that bytecode enhancement would determine the line number and we would use that but that was a bad idea and we ended up with lineNumber always as 0.
These days with StackWalker and DProfileLocation we can do this better that way so yeah. A followup to this is to add to the api a boolean flag as to whether a profile location should be with line numbers (which can change frequently due to refactoring etc)
Rob Bygrave