Hi, I'm facing a simple REST request: I'm trying to filter a child table directly via the field used for the foreign key on the master table. But this does not exist, it is not created. I can't use "$filter = " on that field.
Question: why are these properties omitted when generating the mapping?
I have a parent class (let's say master) of 1200 fields and a class related as details (let's say child).
But I can't directly filter the child table, but I can only "derive" by forcefully loading the master table. E.g. "http://myserver:2001/xdata/master(1)/ChildList".
This process is very slow.
How can I get instead: "http://myserver:2001/xdata/child/?$filter= Masterkeyfield eq keyvalue" avoiding necessarily querying the master?
Clearly the very simple problem also concerns Aurelius...
First you should add that association in your child class. One you add it, you can filter it normally as sub properties:
http://myserver:2001/xdata/child/?$filter=Master/Id eq keyvalue
Thank you Wagner,
but in this way the performances are very low because the system is forced to generate a useless and slow left join when instead it can simply perform a "where keyvalue= 1000" with great performance.
Now is not optimized.
Furthermore there is an equally important problem: I need to copy data between "podo" classes and Aurelius classes to perform very complex calculations. But I am missing all the values of the fields used in the foreign keys. How to do? If I manually add the properties relating to the missing fields (used in foreign keys and not automatically generated) in the classes, are they handled normally or are there exceptions?
Thanks in advance.
I did a quick test by manually adding the property and it seems to work (including the correct query)...
I understand you solved your issue, then? Can you please share the solution for other users?
I simply added the missing field in the class (the field used for the foreign key to the master, in this case let's say "masterkey"). So I was able to do a $filter=masterkey on that field, as I expect is normal. The generated query is then optimized with a "where masterkey= myvalue", without the need to generate a query with a join.
This approach is very important to have all fields valued in the class when copying data into another custom class or for lookup queries, especially within services.
Unfortunately we look for the best performances to compare ourselves with our competitors.
I will have to do some extensive testing to confirm that there are no problems, but at this point there is one important thing missing:
The possibility, as an option, of being able to automatically generate the fields needed for the relationships in the classes (which are already present in the DB), via Aurelius/Generate entities from database... or with Tms Data Modeler