-
-
Notifications
You must be signed in to change notification settings - Fork 260
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ebean should support also IN for local encrypted properties. #2774
Comments
The implementation detail for this to do database side (using database functions) probably isn't conducive to IN. Have you looked at how this could be done with IN (especially on non-Postgres dbs that don't have array binding)? Everything is doable but my impression is that this would probably be messy implementation wise. Do you need this functionality? |
Oh, are you saying ONLY for client side encryption support this case? |
Yes, I meant client side encrypted properties. I can check, if it will also work with server side encryption. |
…or-in #2774 Locally encrypted properties can be used in "in" queries
closed. See #2872 |
Add Postgres specific support for binding an array of byte[] with ANY(?) which is used as with client side encryption where the bind values are implicitly converted to byte[]. Fixes Postgres specific failure running TestEncryptClientSide.java
Add Postgres specific support for binding an array of byte[] with ANY(?) which is used as with client side encryption where the bind values are implicitly converted to byte[]. Fixes Postgres specific failure running TestEncryptClientSide.java
Tidy up MultiValueBind.toArray() only
… prop.isDbEncrypted() and prop.isLocalEncrypted()
While the current documentation is very clear, that EQ (and only EQ) is supported for encrypted properties, I noticed, that IN is currently not supported (which is semantically only a concatenation of multiple EQ queries)
So the documentation is right here ;)
I ponder if all exact match queries ("eq","ne","in","notIn") should work for encrypted properties? I see no technical reason, why they should not.
What do you think?
Expected behavior
should work
The text was updated successfully, but these errors were encountered: