@dogan.ay we think the problem only arises with STRING fields.
No way to tell you the query, as the problems is raised while building the where clause, so no query is built… See the explanation below. We tried to debug the problem in your code. Follow along, please.
Inspecting the error in the log we started looking at the QueryConverter.getWhereFromConditionTree
.
We’ve added a console.log just before the call to QueryConverter.makeWhereClause
(next step in the stack trace).
and the error gets generated at the first field it finds with snake case:
With these details we can know that the makeWhereClause
is then calling QueryConverter.makeLikeWhereClause
At this point looking at makeLikeWhereClause
we can see that it tries to get the safeField
again.
Doing this it does the last jump of the stack trace to unAmbigousField
, which having both isSafe and isRelation false executes the third branch of the if chain
between all the attributes returned from model.getAttributes()
we see the shipyardOther
one
the problem is that since the safeField was passed at the beginning ('shipyard_other'
) instead of the model field ('shipyardOther'
), then we have that model.getAttributes()[field]
is undefined (ofc) and that then causes the error.
This is the reason why in the patch we passed the field instead of the safeField.
So, because the error happens while generating the where clause, we can’t report here the query it does (because it doesn’t do any).
However, with the patch we suggested here’s the query (correct)
In your example everything works correctly because you’ve declared the idMachine
as integer, so the where clause generated is a '='
, while if you try setting it as a string (or also setting lastName from your example, which I’m guessing already is a string) it should generate an 'ILIKE'
and hence generate the error.
Hope this better explains the error, letting you reproduce on your side.