Custom Query Options and Server Driven Paging


  • Why are custom query options removed from the next link containing the continuation token?
    Are there any way to get them on the next link?

    I am writing our own Custom Provider and am currently planning on supporting free text query functionality. I was thinking of having the free text query string supplied in a custom query option since it is not really part of the entity. Ebay's OData API seems to do it like this, but I can't figure out how they do their paging. I need the free text query string to be present on subsequent requests thru the paging "next" mechanism otherwise the queries for the second, third, ... pages will return wron results since the free text criteria will be missing.

    What is the best approach for this?

    Is the client expected to add the Query Options on every page fetch?

    Should I somehow include the Query Options in the continuation token and handle this in my custom paging provider?

    Monday, April 02, 2012 9:11 AM

All replies

  • Hi Uffe,

    There is "skip" and "top" api for paging.


    Have a nice day.

    Alan Chen[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, April 03, 2012 8:05 AM
  • Yes, but that has nothing to do with server driven paging. Server driven paging uses the skiptoken. You have a default implementation and it is possible to define your own mechanism by implementing IDataServicePagingProvider in your own custom provider by doing this you get control over the skiptoken parameter of the otherwise auto generated next link uri. You have no option to reinclude custom properties in the next link uri.


    Consider the following request matches something like 200 persons, and you have a server page size of 50, you will only get the first 50 from the server and a link to the next...

    odata.svc/Employees?customProp=ABC&$filter=Name eq 'Alan'

    The next link is somthing like this

    odata.svc/Employees?$filter=Name eq 'Alan'&$skiptoken='50'

    I would like it to still include the customProp non OData query option like this:

    odata.svc/Employees?$filter=Name eq 'Alan'&$skiptoken='50'&customProp=ABC

    Are there any way to have cutom properties propogate to the nex link uri like this?

    Tuesday, April 03, 2012 1:34 PM
  • Hi Uffe

    Today I found the same problem in one of my implementation Thanks for bringing this to forum,

    I am not sure if there any way to alter this default behavior of  data service run time .

    Easiest approach would be to accommodate at client side implementation but this will have an downside that existing tools will not be able to understand.

    I am also looking for some amicable work around , Let`s see.



    Tuesday, April 03, 2012 6:23 PM
  • Nobody knows?
    Monday, April 09, 2012 8:24 PM
  • Hi Uffe,

    I have brought the issue to the attention of the product group. You may want to also submit the issue to our connect site: and have others vote for it.

    Another option is to have a support case created for a more in-depth level of support.  Please visit the below link to see the various paid support options that are available to better meet your needs.;en-us;offerprophone


    Cathy Miller

    Tuesday, April 10, 2012 2:07 AM
  • Hi Cathy,

    Thanks for your response.

    So, are you saying that this a bug?


    Tuesday, April 10, 2012 1:28 PM
  • Hi Uffe;

    It's not entirely clear whether custom query options should be blindly appended to the next page request.

    By their nature we don't understand the semantics of custom query options, and blindly appending them to each page may yield unwanted results. In most cases, like yours, it does make sense to include the custom query options, but there could theoretically be some cases where the custom option is something you want to vary on a request by request basis for each individual page, rather than enforce across requests. Because of the way WCF Data Services processes requests, there is no easy way for us to "take back" a query option that has been passed as part of the request, so it's safer for us to pass only the information we understand.

    IDataServicePagingProvider gives the data service provider the ability to specify whatever additional custom information it needs in order to correctly process the next page request. It is less convenient, but safer.

    We have opened a bug to consider whether the theoretical case of appending an unwanted custom option is worth the known inconvenience of requiring the provider to implement IDataServicePagingProvider, and whether this is something we can change at this point without breaking backward compatibility.

    In the meantime, your best solution is, as you suggest, to implement IDataServicePagingProvider and encode the additional information in your token.

    I hope this helps,

    Michael Pizzo

    Principal Architect, Microsoft


    This posting is provided "AS IS" with no warranties, and confers no rights

    Tuesday, April 10, 2012 5:20 PM
  • Thank you Michael. This is the kind of answer I was looking for.

    Luckily I already have my own implementation of IDataServicePagingProvider, so this work around is acceptable for now.

    Might I add, that I agree that you probably shouldn't blindly add custom query options to the next link - all sorts of garbage is passed in this way from some client types. But it would be very nice to have the possibility to add custom query options in an IDataServicePagingProvider implementation so the provider that knows something about some custom query options could add them to the next link. Currently you only get control of the $skiptoken query value.



    Tuesday, April 10, 2012 7:16 PM
  • Sorry Michael,

    It is not going to work correctly with encoding the custom query options in the skiptoken.

    The problem is in situations where the query also contain $inlinecount=allpages.

    Queries with $inlinecount=allpages results in two diferent queries executed on the underlying provider. The first one is the one representing the count (the LongCount expression). For the LongCount query the IDataServicePagingProvider method SetContinuationToken is NOT called (and it shouldn't since inline counting disregards the paging). Then I have no way of restoring the custom query options to get the correct total count on page 2, 3....

    So for inlinecount i get the wrong results on subsequent pages. The actual data on the other hand will be correct with the proper implementation in the paging provider.

    I could add an extra handling of the skiptoken to the override of OnStartProcessingRequest but it gets very very hacky then.

    Please add a mechanism in the IDataServicePagingProvider to enable me to actually add custom query options to the next links.



    Wednesday, April 18, 2012 12:52 PM