-
Notifications
You must be signed in to change notification settings - Fork 13
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
$expand clause does not work on result sets #200
Comments
Thanks for reporting this. Can you help us narrow down what got broken by comparing both requests (working single-expansion and broken set-expansion) and figuring out where they start behaving differently from your expectation? |
Here an example of output for a service with this definition: Metadata.txt Entity type "Tabela" (entity set "Tabelas") has 2 navigation properties "Campos" and "CamposChave" leading to collections of entity "Campo".
|
G'day bud, I have been working through your issue today which is quite a hard hitter. We are still chasing it down. but i just wanted to seek some information. with relation to the data in the expanded values (the CamposChave) was there any language specific bits (umlaut, accents, etc) that got trimmed from the outputted data or the saved txt file? because we thing this issue might be character set related. But you will be happy to know we can reproduce it and are working on it |
I have checked my examples, the one I send you, and others I have, and did not found any language specific character set. But in my debug trace I see a difference in the calls being done to my query provider functions. In version 0.2.0 the sequence of calls was:
In current version the sequence is different:
I assume this is not an intended change, even if from performance POV it could be good to have my function for the expand returning all the results for all entries, this would only work if the target type of the navigation contains all the keys from the source plus one more at least. But OData definition does not impose this pure relational scheme (which is good). |
You are correct, it was not an intended change. and it defiantly narrows down the search space. we should be able to get ontop of it for you. On a side note, what tool did you use to generate and analyze the debug trace? |
No special tool, what I call the debug trace is just a log file. I have my own-made framework (kind of old, but still working for me) which I use to build PHP apps and the debug log is one of the functions. |
@cdcampos, @c-harris , I've come up with a fairly minimal test case for the aspect of this bug that I'm seeing at my end of things (trying to expand an entry property, not a feed). What I'm seeing now is intermittent inline failure (first inlined model displays well enough, but nothing later), but the same pattern of getResourceSet / getRelatedResourceReference calls that @cdcampos has reported. I've managed to narrow down where it goes off the rails - executeGet() in UriProcessorNew. That's a bit of a surprise - from what @c-harris was saying, he was suspecting serialisation. |
I think that #201 fixes this issue. |
Yes, it is working now, I confirm. |
Sweet, thanks for your feedback, patience and help. |
My own testing has revealed that I sort of over-egged the pudding in #201, and I've had to revert one of the involved commits. In light of that, cdcampos, is this still fixed? |
Yes, still works 👍 |
Sweet, thank you. Back this issue goes. |
Since version 0.3.0 $expand clause applied to a query that returns a set does not work. Works fine when $expand is used on a query for single record.
This works, "Orders" navigation is returned inline with record of customer "ALFKI":
http://localhost/NorthWind.svc/Customers(‘ALFKI’)?$expand=Orders
This does not work, since version 0.3.0, "Orders" navigation is not returned inline with any record of resulting set:
http://localhost/NorthWind.svc/Customers?$expand=Orders
The text was updated successfully, but these errors were encountered: