Eclipse Community Forums: EclipseLink » Multitenant per table and native query

Home » Eclipse Projects » EclipseLink » Multitenant per table and native query

Multitenant per table and native query [message #1811242]

Thu, 29 August 2019 06:26

Eclipse User

Hello

I'm using EclipseLink 2.6 with Multitenant setted to Tenant per table.
In my test, I found native queries like update and insert, runned by Query.executeUpdate(), working good by replacing table names in queries with table suffixed.
But native select queries, runned by Query.getSingleResult or Query.getResultList doesn't work: table names are not replaced.

EclipseLink documentation reports about "named native queries" are not supported; this made me think like all native queries are not supported, but update and insert made me believe!!

What's the real?

Thank a lot!

Re: Multitenant per table and native query [message #1818973 is a reply to message #1811242]

Fri, 03 January 2020 14:27

Eclipse User

Can you elaborate, maybe add an example, of what you mean when you say "native queries"? Native queries in JPA refer to user defined SQL queries - something that won't work in table per tenant multi tenant environments as EclipseLink doesn't touch or change that SQL in anyway so wouldn't do any table name replacement. Could you have meant a named query instead of a native query?

MT has some quirks and vaguely remember some issues with per table MT that had me remove named queries, but not the specifics - it was a proof of concept and management went in a different non-MT direction. You might want to provide the exact details of what you have configured and file a bug to have the behaviour fixed.

[Updated on: Fri, 03 January 2020 14:28] by Moderator

Re: Multitenant per table and native query [message #1819141 is a reply to message #1818973]

Wed, 08 January 2020 12:13

Eclipse User

Chris,

The multi tenancy feature in eclipselink is also causing me problems for native queries.

Before the entity was modifed with @Multitenant annotation, native query worked.

After adding:
@Multitenant(MultitenantType.TABLE_PER_TENANT)
@TenantTableDiscriminator(type = SCHEMA, contextProperty = MULTITENANT_PROPERTY_DEFAULT)

the native queries are giving the following error:

Caused by: java.lang.NullPointerException: null
at org.eclipse.persistence.internal.helper.NonSynchronizedVector.addAll(NonSynchronizedVector.java:315) ~[org.eclipse.persistence.core-2.7.5.jar!/:na]
at org.eclipse.persistence.queries.ObjectLevelReadQuery.getSelectionFields(ObjectLevelReadQuery.java:1808) ~[org.eclipse.persistence.core-2.7.5.jar!/:na]
at org.eclipse.persistence.internal.queries.CallQueryMechanism.prepareSelectAllRows(CallQueryMechanism.java:308) ~[org.eclipse.persistence.core-2.7.5.jar!/:na]
at org.eclipse.persistence.queries.ReadAllQuery.prepareSelectAllRows(ReadAllQuery.java:910) ~[org.eclipse.persistence.core-2.7.5.jar!/:na]
at org.eclipse.persistence.queries.ReadAllQuery.prepare(ReadAllQuery.java:841) ~[org.eclipse.persistence.core-2.7.5.jar!/:na]
at org.eclipse.persistence.queries.DatabaseQuery.checkPrepare(DatabaseQuery.java:673) ~[org.eclipse.persistence.core-2.7.5.jar!/:na]

Any suggestions or workaround appreciated!

Thanks

Kevin

Re: Multitenant per table and native query [message #1822555 is a reply to message #1819141]

Mon, 09 March 2020 14:48

Eclipse User

Named queries in MT are processed against the uninitialized ServerSession, and so won't work with MT in its current form. I switched my named queries to all be created within the app to workaround the issue on my table/schema per tenant proof of concept work early on to workaround it.
I think I have some fixes locally to get things 'working', but I'm not sure how viable they are for the product as is - one of my changes was to modify AbstractSession so that getRootSession returns 'this'. A change that is fine for my project locally (or seems to be) as all descriptors are MT and should be using the leaf Session for queries, but not for the product overall. It might resolve the issue with named query processing, but I'm not confident in it - processing of them needs to be delayed until after the MT context is set, which might defeat the reusability of named queries overall anyway, so you are likely better with a workaround of creating them on demand for now.

If you have support contracts to leverage, please do, otherwise file bugs in EclipseLink's bug tracker with simple test cases and we can get votes (or even test partial solutions to see what they help with) to get it resolved.

Sorry.

Previous Topic:	Merge trying to delete an existing entry while trying to add a new entry
Next Topic:	Insert using identity column and trigger returns wrong primary key

Goto Forum:

-=] Back to Top [=-

Current Time: Thu May 08 00:58:58 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter