We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. Image for the cookie policy date
close icon

OData v4 - Guids are in the wrong format

Hello everyone!

I'm currently evaluating the KanBan board using OData v4 as a data adapter. I noticed, that it is automatically converting strings that look like guids to the format guid'00000000-0000-0000-0000-000000000000' when querying. As far as I know, this is the syntax for OData <= 3, in OData v4, the syntax is just the guid without any quotes. Therefore, my OData endpoint using Microsofts OData for WebApi fails when the requests are fired.

Is this a bug in your component, or am I doing something wrong? Sorrily, the documentation on OData v4 with the DataManager is very sparse. So far, I have figured out a workaround using the beforeSend callback to manipulate the url:

beforeSend: function(dm, p, xhr) {
    xhr.url = xhr.url.replace(/guid'([0-9A-F]{8}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{12})'/ig, '$1');
}

Even here, the documentation I found is wrong. If you look here https://help.syncfusion.com/api/js/ejdatamanager#callbackfunctions:beforesend, you will see the signature of the beforeSend callback is defined as beforeSend(request, settings). I found, the first parameter is the data manager itself, the second was also something completely different, and the third parameter is the actual XmlHTTPRequest object, on which you can manipulate the request.

So, any pointers on how to do it right are welcome. Thanks in advance!

Cheers,
Christoph

9 Replies

AP Arun Palaniyandi Syncfusion Team April 12, 2018 06:20 AM UTC

Hi Christoph, 
 
Thanks for contacting Syncfusion support. 
 
Query1: I'm currently evaluating the KanBan board using OData v4 as a data adapter. I noticed, that it is automatically converting strings that look like guids to the format guid'00000000-0000-0000-0000-000000000000' when querying. As far as I know, this is the syntax for OData <= 3, in OData v4, the syntax is just the guid without any quotes. Therefore, my OData endpoint using Microsofts OData for WebApi fails when the requests are fired. 
 
Sorry for the inconvenience. 
 
We have support for GUID in dataManager and we were unable to reproduce the reported issue in our end with the provided details. Can you please provide us additional details on the following? 
 
·         How GUID is generated in your code? 
·         Share us code snippet and query details which you are using for filtering GUID field. 
·         Share us details on the OData service parameter data type details and how GUID is passed in the service 
·         If possible share us an issue reproducible sample or a video to showcase the issue so that we can proceed further. 
 
 
Query2:” Even here, the documentation I found is wrong. If you look here https://help.syncfusion.com/api/js/ejdatamanager#callbackfunctions:beforesend, you will see the signature of the beforeSend callback is defined as beforeSend(request, settings). I found, the first parameter is the data manager itself, the second was also something completely different, and the third parameter is the actual XmlHTTPRequest object, on which you can manipulate the request.So, any pointers on how to do it right are welcome” 
 
Regarding the documentation revamp for DataManager, we have considered your feedback. Hence we will improve document of dataManager in any of our upcoming releases. 
 
 
Please let us know if you have any queries further. 
 
Regards, 
Arun P. 



CH Christoph Herold April 12, 2018 09:48 AM UTC

Hi Arun,

it is actually very easy to reproduce. You can see it at: http://jsplayground.syncfusion.com/jnincpch
I've just created a basic ODataV4 based DataManager, put it in the kanban board, and made the keys of the columns look like guids (although they are technically just strings).
Please ignore the fact, that the OData service url does not exist, but in the developer tools of your browser, you will see the request being made:

http://jsplayground.syncfusion.com/Whatever/OData/?$count=true&$filter=(Status%20eq%20guid%2700000000-0000-0000-0000-000000000000%27)%20or%20(Status%20eq%20guid%2700000000-0000-0000-0000-000000000001%27)%20or%20(Status%20eq%20guid%2700000000-0000-0000-0000-000000000002%27)%20or%20(Status%20eq%20guid%2700000000-0000-0000-0000-000000000003%27)

And in the $filter parameter, you can see the "guid%2700000000-0000-0000-0000-000000000000%27" parts. This is just plainly the wrong format for an OData V4 service.

Kind regards,
Christoph


KR Keerthana Rajendran Syncfusion Team April 17, 2018 01:04 PM UTC

Hi Christoph, 
 
As per your requirement, we can achieve the scenario by using custom adaptor. We have created the query in the source as per the OData protocol norms. Please refer to the below blog  
  
  
  
 So we are validating this with Odata service right now and raised query in the below blog.   
  
  
So, please use the below workaround for now. Change the adaptor to custom adaptor through create event of Kanban and modify the query through processQuery as shown below 
  
<script>   
    function onLoad(args) {   
        this.model.dataSource.adaptor = new customadaptor();//extend the adaptor    
    }    
    var customadaptor = new ej.ODataV4Adaptor().extend({    
        processQuery: function (dm, query, hierarchyFilters) { // processing the query   
            var query = ej.ODataAdaptor.prototype.processQuery(dm, query);    
            var str=query.url.replace("guid'""");   
            str=str.replace("'""");   
            return {    
                type: "GET"   
                url: str,    
                ejPvtData: this.pvt    
            };    
        },            
    });    
</script>   
  
   
You can modify the query based on your requirement in processQuery 
  
Regards,  
Keerthana.  
 



CH Christoph Herold April 17, 2018 08:40 PM UTC

Ok, so you're basically doing the same thing as my workaround, i.e. post-process the url and strip out the guid'...' wrapper, just at another stage in the pipeline (processQuery, as opposed to beforeSend). However, your version will also remove all single quotes, which will break any regular string filters added to the query. It's nice, that this can be done, although figuring this out based on the documentation is practically impossible, since the topic is so sparsely documented.

And, as per the links you posted, it still leaves the issue of the basic implementation not being according to the OData V4 specs, since guids should be written without the guid'...' wrapper when using V4. Is this a bug, that will be fixed in one of the next versions, or will this behavior always need to be worked around?

Cheers,
Christoph


KR Keerthana Rajendran Syncfusion Team April 18, 2018 04:07 PM UTC

Hi Christoph, 
 
We will update the processQuery details of dataManager document in future document improvement. We have considered your requirement as bug and we will fix this issue in our end. We request you to use the provided workaround till then. 
 
Regards, 
Keerthana.  



CH Christoph Herold April 18, 2018 04:28 PM UTC

Ok, thank you for the update. I'm looking forward to the bugfix!

Cheers,
Christoph


KR Keerthana Rajendran Syncfusion Team April 19, 2018 09:48 AM UTC

Hi Christoph, 
 
Most Welcome. This fix will be included in our Volume 2, 2018 release which will be rolled out by the end of May. 
 
Regards, 
Keerthana. 



AN Adriano Nascimento August 9, 2019 05:17 PM UTC

Hello everyone.
I am having the same problem using @syncfusion/ej2-data in Angular. I was able to work around the issue by customizing ODataV4Adaptor, but there is some fix prediction.


PS Pavithra Subramaniyam Syncfusion Team August 14, 2019 03:53 AM UTC

Hi Adriano, 
 
We have logged a bug task for the reported issue as “Filter query string is in wrong format for GUID with OdataV4 adaptor.”. Thank you for taking  time to report this issue and helping us improve our product. At Syncfusion, we are committed to fixing all validated defects (subject to technological feasibility and Product Development Life Cycle ) and including the defect fix in our upcoming Patch Release which will be rolled out by end of August, 2019. 
 
Until then we appreciate your patience.  
 
You can now track the current status of your request, review the proposed resolution timeline, and contact us for any further inquiries through this link.  
   
 
Regards, 
Pavithra S. 


Loader.
Live Chat Icon For mobile
Up arrow icon