You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The list method with max params returns a PagedResultList. This class obtains the resulting list by calling org.hibernate.query.Query.getResultList, which does not fire the preQuery event that is neccesary for the TenantResolver to be invoked.
This makes the list method to use the last tenant id used in the session, instead of resolving the current one, or issuing a query without a tenant.
For example, the next test will fail, because as we clear the tenant id, the list method should throw an error.
void"Test list with 'max' parameter"() {
given: "Create two Authors with tenant T0"System.setProperty(SystemPropertyTenantResolver.PROPERTY_NAME, 'TENANT')
MultiTenantAuthor.saveAll([newMultiTenantAuthor(name: "A"), newMultiTenantAuthor(name: "B")])
when: "Query with no tenant"System.setProperty(SystemPropertyTenantResolver.PROPERTY_NAME, '')
MultiTenantAuthor.list([max: 2])
then: "An exception is thrown"
thrown(TenantNotFoundException)
}
If you run this, you can see the query that it is being used:
However, if we use the list method without any parameters, it works correctly and raises the exception.
Another test:
given: "Create two Authors with tenant T0"System.setProperty(SystemPropertyTenantResolver.PROPERTY_NAME, 'TENANT')
MultiTenantAuthor.saveAll([newMultiTenantAuthor(name: "A"), newMultiTenantAuthor(name: "B")])
when: "Query with the same tenant as saved, should obtain 2 entities"System.setProperty(SystemPropertyTenantResolver.PROPERTY_NAME, 'TENANT')
then:
MultiTenantAuthor.list([:]).size() ==2when: "Query by another tenant, should obtain no entities"
datastore.sessionFactory.currentSession.clear()
System.setProperty(SystemPropertyTenantResolver.PROPERTY_NAME, 'OTHER TENANT')
def list =MultiTenantAuthor.list([max: 2])
then:
list.size() ==0
Again, this fails because the list method with max parameter, is using the first tenant id 'TENANT' (because it wont fire the preQuery event..). You can see that the query used is:
selectmultitenan0_.idas id1_0_,
multitenan0_.versionas version2_0_,
multitenan0_.tenant_idas tenant_i3_0_,
multitenan0_.nameas name4_0_
from
multi_tenant_author multitenan0_
where
? =multitenan0_.tenant_idlimit ?
[Test worker] DEBUG org.hibernate.type.descriptor.sql.BasicBinder- binding parameter [1] as [VARCHAR] - [TENANT]
fjloma
changed the title
Multi Tenancy issue with list method with max params
Multi Tenancy issue, list method with max params not resolving the current tenant id
Mar 24, 2022
This is also related to this issue grails/grails-data-mapping#1379
The first, last, and findAll(with max param) methods have the same problem, because they call internally to the list method with max param.
…urrent tenant id (#539)
* Multi-tenant issue fix. The list method with parameters is not resolving the current tenant id
See #537
* More tests for first, last and findAll, with the same issue with max parameter
The list method with max params returns a PagedResultList. This class obtains the resulting list by calling org.hibernate.query.Query.getResultList, which does not fire the preQuery event that is neccesary for the TenantResolver to be invoked.
This makes the list method to use the last tenant id used in the session, instead of resolving the current one, or issuing a query without a tenant.
For example, the next test will fail, because as we clear the tenant id, the list method should throw an error.
If you run this, you can see the query that it is being used:
However, if we use the list method without any parameters, it works correctly and raises the exception.
Another test:
Again, this fails because the list method with max parameter, is using the first tenant id 'TENANT' (because it wont fire the preQuery event..). You can see that the query used is:
I've created a fork with this tests and a possible fix here: https://github.com/fjloma/gorm-hibernate5
The text was updated successfully, but these errors were encountered: