I had the following code, which was running well with EF Core 2.1:
.FirstOrDefault(a => (a.Name.Equals(b, StringComparison.InvariantCultureIgnoreCase).
(Ok, running well means I got the right results even if it was being evaluated in the client side and I didn't know it).
I updagred to EF Core 3.0 and I didn't get any error, but this code was not giving the expected results.
I saw here a solution. I tried a.Name.ToLower() == b.ToLower() but then I got the the error:
Error CA1304 The behavior of 'string.ToLower()' could vary based on the current user's locale settings. Replace this call in 'MyFunction(string, string)' with a call to 'string.ToLower(CultureInfo)'
If I use a ToLower(CultureInfo.InvariantCulture) I get the message:
Error CA1308 In method 'MyFunction', replace the call to 'ToLower' with 'ToUpperInvariant'.
If I use ToUpperInvariant(), then I get the error (I'm already aware of the LINQ breaking changes in EF Core 3.0):
The LINQ expression (... all the expression...) could not be translated. Either rewrite the query in a form that can be translated, or switch to client evaluation explicitly by inserting a call to either AsEnumerable(), AsAsyncEnumerable(), ToList(), or ToListAsync().
So, I am the starting point.
Is there a way to both comply with CA1304 and run the query in the DB and not in the client side?
The solution, as PanagiotisKanavos commented, was to simply use a.Name == b. Easy and it works!
Related
I have recently been trying to upgrade flyway from v4 to v6.5.3. During the process, I faced an issue related to placeholders.
The migration fails with the following error.
ERROR: Unable to parse statement in
D:\Softwares\flyway-commandline-6.5.5-windows-x64\flyway-6.5.5\sql\V3__mysql-7.0.sql
at line 101 col 1. See
https://flywaydb.org/documentation/knownparserlimitations for more
information: No value provided for placeholder: ${'), NOW(), NOW())}.
Check your configuration! Caused by: No value provided for
placeholder: ${'), NOW(), NOW())}. Check your configuration!
SQL,
insert into `configuration`(key, value, created_date , updated_date) values('LOG_LOCATION', REPLACE('${MY_LOG_LOCATION}','#{','${'), NOW(), NOW());
To resolve the above failure, I replaced "${" with "$\{", but this is something I didn't look out for.
On debugging the flyway code, I saw it fails in parsing (during validation, method org.flywaydb.core.internal.parser.Parser.readToken()) of the SQL.
Why is it considering the 3rd argument of REPLACE function as a placeholder?
Note: The above SQL works in Flyway v4
If you read the documentation here, you can see that flyway uses a particular syntax for it's placeholders, ${somestring}. In your code, you have a ${, but it's not defining a placeholder. While Flyway is a pretty sophisticated tool, the mechanism here is simply using string matching. If you want to, you can modify your Flyway instance to use different escape characters for the placeholders. This could be handy if you have to have strings in your code that match that ${ syntax. You can read about that here. Scroll down to where you define the PlaceHolderPrefix and PlaceHolderSuffix. Change those to a different combination of values that are not used in your code and you should be fine.
I try to manipulate a CosmosDB (SQL) using entity framework core 3.0 (Microsoft.EntityFrameworkCore.Cosmos 3.0.0).
Everything works fine except when I try to use Contains, StartWith, …
For example:
var query = _context.Challenges.Where(c => c.Name.Contains( "string"));
EF is supposed to translate it to the following SQL (that works perfectly on the CosmosDB – Query Explorer)
SELECT * FROM c WHERE CONTAINS(c.Name, "string")
But I receive the following error message:
The LINQ expression 'Where<Challenge>(\n source: DbSet<Challenge>, \n predicate: (c) => c.Name.Contains(\"string\"))' could not be translated.
Either rewrite the query in a form that can be translated, or switch to client evaluation explicitly by inserting a call to either AsEnumerable(), AsAsyncEnumerable(), ToList(), or ToListAsync().
See https://go.microsoft.com/fwlink/?linkid=2101038 for more information.
Of course, I don’t want to code it like the following, that will execute the entire contains on the client, just to make a simple LIKE…
List<Challenge> entities = _context.Challenges.AsEnumerable().Where(c => c.Name.Contains( "string")).ToList();
Anyone has an idea of to evaluate the "contains" on the server side ?
Note: I try the exact same code using UseSqlServer rather than UseCosmos (and by adding the needed [Key] annotation and creating a SQL server) and it works like a charm.... So it's a definitively a CosmosDB vs EF issue.
By posting the same issue on entity framework core forum (https://github.com/aspnet/EntityFrameworkCore/), the answer was that this feature is not yet implemented:
https://github.com/aspnet/EntityFrameworkCore/issues/18673
https://github.com/aspnet/EntityFrameworkCore/issues/16143
https://github.com/aspnet/EntityFrameworkCore/issues/18451
https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/6333414-implement-like-keyword
We are working on moving some projects from AEM 6.0 and 6.2 one of the applications has an error and documentation hasn't been helpful.her is the reduced case querybuilder query
type=cq:page
path=/content/nera/en/experts
p.hits=full
p.nodedepth=1
1_property.opertaion=like
1_property=jcr:content/jcr:title
1_property.value=Dr.
The issue is that even though the operation is set to like only full matches are returned. partial matches return no results however on AEM 6.0 partial results are returned. In my case the value of "Dr." returns nothing while Dr. Lawrence Wu which is an existing node returns the page.
Any help appreciated
You have a typo or probably an error in your sample/code:
1_property.opertaion=like
instead of:
1_property.operation=like
Beside this, I don't thing that there is any difference in the QueryBuilder implementation between 6.0 and 6.2. All query builder queries are converted to SQL2 before they are executed. You can set the log level to DEBUG for the following packages in order to see the actual queries in your log:
org.apache.jackrabbit.oak.query
com.day.cq.search
You can also test your queries using the query debug servlet and see what xpath is produced in the end. The option p.hits=full controls only if all properties are included in the result or just a small set of them (e.g. path, name, title, etc.)
I changed Change in persistence.xml
I also changed column definition (columnDefinition="XDB.XMLType") for xml fields
I checked OpenJpa(http://openjpa.208410.n2.nabble.com/Oracle-XMLType-fetch-problems-td6208344.html) site and IBM (http://www.ibm.com/support/knowledgecenter/SS7J6S_7.5.0/com.ibm.wsadapters.jca.jdbc.doc/env/doc/rjdb_problemsolutions.html)
My env is OpenJpa 2.0 and WAS 7
its throwing exception
org.apache.openjpa.persistence.PersistenceException: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at "SYS.XMLTYPE", line 169
Please suggest without changing OpenJpa2.0 as its part of IBM WebSphere Application Server V7.0 how can i handle sys.XMLTYPE data, i am migrating my application from db2 to Oracle in same environment.
Writing XML data can be tricky some times! Getting the correct drivers and things defined properly can have its challenges. I can not say exactly what you need to do given the lack of info on your domain model and such, but let me give some general things to look for. First, there is an XML test in the OpenJPA test framework if you want to make reference to it. It can be seen publicly here:
https://apache.googlesource.com/openjpa/+/refs/heads/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/jdbc/oracle/
Or, another test using an "XMLValueHandler" (likely this is beyond the scope of what you are looking for):
https://apache.googlesource.com/openjpa/+/refs/heads/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/xmlmapping/query/
Second, (stating the obvious) I assume you have a column in Oracle defined as "XMLTYPE". Also, I see you are using schema SYS. I'm sure you are aware but this is a system/admin schema......just for sanity sake you might want to first get things running using a non-system/admin schema just so we don't get hung up with any issues with your OpenJPA client not having the correct permissions.
Next, you need the following definition:
#Lob #Basic
#Column(name = "ANXMLCOLUMN", columnDefinition="XMLCOLUMN XMLType")
private String anXMLString;
The #Lob I think will be necessary if you are using data greater than 4000 chars (this was mentioned in one of the comments). To start I'd use a very small set of data (a couple characters), once that works, then experiment with > 4k.
Next, make sure to use the correct JDBC driver. The last time I experimented with an XMLType I used the Oracle JDBC 11.2.0.2 driver.
Finally, you might need to use the property "openjpa.jdbc.DBDictionary" with value "oracle(supportsSetClob=true,maxEmbeddedClobSize=-1)". Again, experiment with this AND look at the OpenJPA documentation on these properties to determine if they are necessary in your scenario. I think the supportsSetClob=true will only be necessary for older version (pre-2.2.x) of OpenJPA. You might also need to use property "openjpa.jdbc.SchemaFactory" with value "native". I would suggest you first try without either or these two properties. If that doesn't help, then experiment with these two properties. I know this is vague, but I don't know what your DDL or domain model looks like so I have to keep in vague.
Thanks,
Heath Thomann
I am getting the following error when I try to start my Application...
[java.lang.IllegalStateException: java.lang.NullPointerException^M
at com.tivoli.pd.jutil.kb$1.run(kb$1.java:41)^M
at java.security.AccessController.doPrivileged(AccessController.java:229
)^M
at com.tivoli.pd.jutil.kb.c(kb.java:141)^M
at com.tivoli.pd.jutil.kb.(kb.java:56)^M
at com.tivoli.pd.jutil.PDContext.(PDContext.java:76)^M
at com.tivoli.pd.jazn.PDAuthorizationContext.(PDAuthorizationConte
xt.java:66)^M
I double checked the config file was accessible and I could read it. The code I am using looks as follows...
aC = new PDAuthorizationContext(cFile);
Is there a way to get more information on what is causing the NPE?
More information!!!
After debuging a bit, it appears the issue comes from this code (they use progaurd so it is a little hard to be 100% confident)...
Certificate[] arrayOfCertificate1 = ((KeyStore)???).getCertificateChain("DefaultID");
//Throws Null pointer (presumably because array is null)
Certificate localCertificate1 = arrayOfCertificate1[0];
EVEN MORE INFO
This appears to be some kind of dependency conflict (guess), because if I just create a sample App using PDAuthorizationContext it works fine.
Problem was related to the PD.jar version that I was using. Although I thought I was using one version I was using another. This was because on version was registered in my WebSphere library (under build path in eclipse). Once the proper library was introduced everything worked.