Hi Isomorphic,
I looked at the serverside com.isomorphic.criteria.criterion.SetCriterion API and saw that it only takes a collection or array as values.
In my (serverside) use-case I get a short (from 1 to ~100) list of IDs with a simple inexpensive query that feed into a SetCriterion and execute my real fetch-query with this.
My suggestion is to support a com.isomorphic.datasource.DSRequest as 3rd parameter in the SetCriterion-constructor or with SetCriterion.setValues().
The DSRequest would never be executed, but the generated SQL for the request would be put as String into the "WHERE field IN (<list>)"-part of the main SQL, resulting in a uncorrelated subquery.
The user would be responsible for using a operation binding that only outputs a single column in the SELECT-list.
Do you think that this is a good enhancement for SmartGWT (serverside). It would save a DB-roundtrip and a DB-call and possibly allow the optimizer to generate a better execution plan.
Best regards,
Blama
I looked at the serverside com.isomorphic.criteria.criterion.SetCriterion API and saw that it only takes a collection or array as values.
In my (serverside) use-case I get a short (from 1 to ~100) list of IDs with a simple inexpensive query that feed into a SetCriterion and execute my real fetch-query with this.
My suggestion is to support a com.isomorphic.datasource.DSRequest as 3rd parameter in the SetCriterion-constructor or with SetCriterion.setValues().
The DSRequest would never be executed, but the generated SQL for the request would be put as String into the "WHERE field IN (<list>)"-part of the main SQL, resulting in a uncorrelated subquery.
The user would be responsible for using a operation binding that only outputs a single column in the SELECT-list.
Do you think that this is a good enhancement for SmartGWT (serverside). It would save a DB-roundtrip and a DB-call and possibly allow the optimizer to generate a better execution plan.
Best regards,
Blama