Hi!
The newly commited test com.avaje.tests.report.TestSqlBasedEntity shows that using Sql based entities as described in the documentation with "ReportTopic" does not work when using a default sql.
The reason is, that @Sql generates raw sql but in DeployBeanDescriptor.isSqlSelectBased it is checked for a _NamedSql_ with name "default" instead of RawSql.
It seems the rawSqlMetas in DeployBeanDescriptor are feed into the namedQuery collections in BeanDescriptorManager.deploy (call to readRawSqlQueries)
However, ebean needs to know the fact that the bean is a report bean earlier (don't know exactly where).
Applying this patch will fix the test:Index: ../opsxcited_3rdpary/ebean/core/src/main/java/com/avaje/ebean/server/deploy/meta/DeployBeanDescriptor.java===================================================================--- ../opsxcited_3rdpary/ebean/core/src/main/java/com/avaje/ebean/server/deploy/meta/DeployBeanDescriptor.java (revision 463)+++ ../opsxcited_3rdpary/ebean/core/src/main/java/com/avaje/ebean/server/deploy/meta/DeployBeanDescriptor.java Wed Sep 09 13:11:14 CEST 2009@@ -269,6 +269,11 @@ if (defaultQuery != null) { return defaultQuery.isSqlSelect(); }+ RawSqlMeta rawSql = rawSqlMetas.get("default");+ if (rawSql != null) {+ return true;+ }+ return false; }
Looking at BeanDescriptorManager... lines 228 - 230
readEntityDeploymentAssociations();...readRawSqlQueries();
... the readRawSqlQueries is called after the first check for isSqlSelect() which is setting the base table to null (as it will default from the naming convention - so must be set to null for entities based on raw sql).
Yes, your patch works and fixes the issue.
I was just wondering about other options instead of the patch above - but I think the patch above is a good solution.
Specifically, the 'parsing' of RawSqlMeta ... occurs late (too late for the initial check to see if the entity is based on sql). I want to keep this because it means that we can (if we want) allow users to programmatically use raw sql queries.
That is, at the moment users need to use the @Sql annotations... and instead we can provide this as API that can be used at runtime. The raw sql and column mapping can be parsed at runtime... giving users programmatic control over the SQL and column mapping.
I think we still want to do that, so I'm happy with the patch... and don't think we can improve on it really.
I have committed the patch into HEAD.