$expand clause does not work on result sets about podata HOT 13 CLOSED

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?

from podata.

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".

1. Requesting a single entry of "Tabelas" with expansion of "CamposChave"
   odata.svc/Tabelas('S_Anexos')?$expand=CamposChave
   results in this output: SingleExpansion.txt
   Element "link" opened on line 11 and closed on line 77 contains the "m.inline" with expansion of "CamposChave". As no expansion of "Campos" was requested, the "link" element for "Campos" (line 10) has no inline.

2. Requesting the collection of "Tabelas" with expansion of "CamposChave"
   odata.svc/Tabelas?$expand=CamposChave
   should result in this output (as it was before version 0.3.0): SetExpansion_OK.txt
   For each entry the "link" element for "CamposChave" have the inline and "Campos" have no inline.

3. But after version 0.3.0 the result is like this: SetExpansion_NOK.txt
   On each entry both "link" elements for "Campos" and "CamposChave" have no inline content.

from podata.

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

from podata.

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:

• one single call to getResourceSet
• multiple calls to getRelatedResourceSet, one for each entry, and in parameter $sourceEntityInstance I receive one instance of my resource class

In current version the sequence is different:

• one single call to getResourceSet
• one single call to getRelatedResourceSet, and in parameter $sourceEntityInstance, now one instance of POData\Providers\Query\QueryResult, containing the collection of my resource class instances in property "results"

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).

from podata.

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?

from podata.

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.

from podata.

@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.

from podata.

I think that #201 fixes this issue.

from podata.

Yes, it is working now, I confirm.
Testing this I found another issue also on $expand: #203

from podata.

Sweet, thanks for your feedback, patience and help.

from podata.

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?

from podata.

Yes, still works 👍

from podata.

Sweet, thank you. Back this issue goes.

from podata.