tag:blogger.com,1999:blog-8643857899806162280.post3553237454633757836..comments2024-02-25T06:15:55.318-03:00Comments on Bug squash: Towards a NuGet dependency monitor with OData and F#Mauricio Schefferhttp://www.blogger.com/profile/15247972578064164206noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-8643857899806162280.post-84730026017734529232013-11-22T12:09:32.811-03:002013-11-22T12:09:32.811-03:00Thanks for a great article. And btw it provoked me...Thanks for a great article. And btw it provoked me to do a comparison between WCF Data Services and cross-platform library Simple.OData.Client that I happen to maintain. I wrote it partly because of the same frustration I experienced while working with WCF DS. You only touched a surface of what doesn't properly work in WCF DS. If you tried to modify data you would come to another set of obstacles. Here's an article with comparison: http://www.codeproject.com/Articles/686240/12-reasons-to-consume-OData-feeds-using-Simple-ODaobjecthttps://www.blogger.com/profile/11602960876612620078noreply@blogger.comtag:blogger.com,1999:blog-8643857899806162280.post-52772273915523262402013-10-31T20:27:27.114-03:002013-10-31T20:27:27.114-03:00Thanks for your comment, Jack. I think the problem...Thanks for your comment, Jack. I think the problem is that you can lift any function into an Expression. There should be some way to limit that per-provider. I think type providers should be able to do this. I don't remember seeing any implementation doing it, though.<br /><br />I'm not really sure anymore it's so useful to have a common API for various data models. LINQ was modeled from relational databases, but it doesn't really fit other kinds of databases. For example, I wrote APIs for <a href="https://github.com/mausch/UrchiNet" rel="nofollow">Urchin</a> and <a href="https://github.com/mausch/SolrNet" rel="nofollow">Solr</a>, and they're so different from relational databases that the standard LINQ syntax wouldn't apply in a lot of cases and it would only be able to express only the most trivial queries in these databases.<br /><br />Since databases are so different in capabilities, models, properties, etc, why try to force them all into a single API? That seems as bad as implementing a .NET interface and having half of the methods throwing NotSupportedException, i.e. the abstraction is too coarse.<br /><br />I'd rather embrace the differences and model the API of each database for what it really is.<br /><br />Datalog sounds interesting, I don't know much about it. But it seems it wouldn't be able to model several features of Solr, like faceting. It seems to be most useful when the database itself is designed to support it.Mauricio Schefferhttps://www.blogger.com/profile/15247972578064164206noreply@blogger.comtag:blogger.com,1999:blog-8643857899806162280.post-57183602424307335122013-10-26T11:59:55.038-03:002013-10-26T11:59:55.038-03:00You really put your finger on problems with IQuery...You really put your finger on problems with IQueryable, especially the inability of users to determine what executes where. Still, it's useful to have a common framework for IO APIs given the general lack of documentation for so many systems we want to interact with, even if every implementation is different. Is there a better alternative? Would a datalog framework be any better, for instance?jackfoxyhttps://www.blogger.com/profile/04700282308838786815noreply@blogger.com