-
Notifications
You must be signed in to change notification settings - Fork 18
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
BUG: Predicate query fails when searching for a text word that is the same as an Entity name. #73
Comments
Not a bug. In this case, you need to use some additional syntax to indicate whether you are querying the literal value or the property. // query where the Title property starts with the Area property
let propertyPredicate = new Predicate('Title', FilterQueryOp.startsWith, { value: 'area', isProperty: true });
// query where the Title property starts with the literal 'area'
let valuePredicate = new Predicate('Title', FilterQueryOp.startsWith, { value: 'area', isProperty: false }); This is in the Breeze documentation, but it's buried pretty deep. |
I attempted to fix this issue in my own application by using |
Can you give me an example of a query that is failing, and what the error is? |
Sorry, I've already made a workaround: to test the value I wanted to query by and only apply I was hoping |
Sorry I don't have more expertise. I've just taken over this project and never heard of Breeze :) In code, my workaround was to do this:
|
Please help me, because I'm trying to reproduce the scenario in the Breeze tests. Let's say I have an entity with three properties, Also, what version of Breeze are you using on the client and the server? |
The server is using In my scenario this
This worked fine
Something about setting that flag caused the query to be built incorrectly. As I mentioned, I have little to no experience with Breeze, just enough to make a workaround for the filtering by property name issue the OP mentioned (I understand there are circumstances where it would be appropriate to have that behavior). If you can't recreate it in your tests, I'm sure something in the architecture of this project is to blame. Thank you for being a good steward of this project. |
The "string couldn't be filtered by Int32" error was caused by this predicate:
This fixed that issue (because I didn't want to filter by the actual property value, I wanted to filter by the literal string....
I was hoping I could just always set |
Thanks for the help. I'll see if I can fix it. I'm glad you found the workaround for you. |
I could not reproduce the problem. The data type of a property -- String, Int32, Double, etc. -- comes from the Breeze metadata, which is consumed by the Breeze EntityManager and usually generated based on the server classes. Your metadata may need updating or correcting. You can also specify the data type explicitly in the predicate: new Predicate("intProp", "eq", { value: 1, isProperty: false, dataType: "Int32" }); |
Consider the following scenario:
I have an entity type called Area that corresponds to an Area table in my database and I have another entity type in the same entity metadata set that contains a Title field, defined as a string, that I want to query against by creating a Predicate something like the following:
I then use my predicate with the EntityQuery.where() method to query my other table which DOES NOT have a field or navigation property called "Area".
The result is that I will receive an error from the EntityManager that states:
This is true when you write any Predicate using any valid FilterQueryOp operator to query for any string that is an exact caseless match of the name of any Entity Type that is registered from a server Metadata call on an Entity Framework Core dbContext.
My current workaround to this is to remove the last character of a "startsWith" predicate or the first character of an "endsWith" predicate, but it gets dicey when I need to use an "equals" predicate, so it would be nice if this bug could be fixed.
The text was updated successfully, but these errors were encountered: