I really want to use Web API but right now it's broken as in can't ever be used in production broken.
That is that it doesn't support $select so you're always select * and you're always returning full objects. (Amature hour at the zoo!)
So $select is just a parameter on the querystring.
And if I could either bind that to a parameter on the method (can't because of the $ right?) or exclude that parameter and have it still match and just get it from the Request.QueryString then I can use linq dynamic to fix this oversite and just return dynamic.
Then when someone at MS comes to their senses and realizes that this is a bad idea and enables $select it's just a matter of removing the extra method and all of the regular ones will work just fine. (or whatever syntax that they require)
I really want to use Web API but right now it's broken as in can't ever be used in production broken.
I'm not so sure that's true. We considered having that feature but decided not to support in V1 for a variety of reasons.
John Galt
when someone at MS comes to their senses
Unfortunately we have to consider deadlines, costs, performance and/or security considerations as well as the opportunity cost of implementing this instead of any number of other desirable features when prioritizing work. We certainly have this on the list
for vNext.
I'm sure you and @marcind have some clue about what you are talking about, but I'm totally lost. Is $select some part of the OData query syntax? I have found Web API very useful for production scenarios and hope to roll some items out soon. I also have no
love for OData, so that may be why I don't understand any of your points above, if that is how $select relates.
If you are using OData, why not just use OData? How does Web API factor into your platform decision? I'm very confused by your seeming animosity towards the library and the team.
However I strongly disagree with your assessment that this isn't an absolute requirement for V1 and that it can be used in production as it is right now:
1. Microsoft's own documentation on SQL Server says that Select * should never be used except in extreme situations because of the performance degradation. (there is even an example of doing an join with select * on both parts of the join as to how aweful
it is on performance)
2. To do a joined resultset to display a list of say contacts and their phone numbers (pretty common and a common pattern for orders, invoices and just about anything else from a relational database (i.e. ef)) you would have to do a select * on the contacts
that you're returning AND SELECT * ON ALL OF THE PHONE NUMBERS. Versus a projection that would return say ContactID, Name, and the Phone Number from the referenced table. Of course this gets expodentially worse as the size of the resultset goes up, but you
get my drift about the absolutely horrible waste of both bandwidth and processing power.
THUS
WebAPI in it's current state leaves one of three choices:
1. Hack it like I am so that the client can control the projections as should be the case.
2. Write a million methods for every permutation and combination of select query that your site or api request could want in the way of fields.
3. Dont' use it and go to something that doesn't force you to write crappy inefficient code. (i.e. the technology that this is supposed to replace!)
Obviously #2 is a non-starter in any large production environment because of the overhead of doing so and the maintainability is almost 0.
Thus unless MS fixes this and adds $select support we're left with hacking it in ourselves. (which is exactly what other people are asking about on stack overflow etc.) or ditiching Web API until some indeterminant point in the future when MS comes to its
senses.
You guys need to sit down in a meeting and be real with yourselves and admit that for this to be at all useful and not a typical Microsoft half-baked V1 product that won't be usable until V3, you must have the ability to return projections specified by the
consumer. Otherwise you're going to end up with either really crappy slow apps that don't scale and people are going to blame MS for why they're crappy and slow.
and/or
0 uptake on this because any educated database person is going to look at what this is doing and put a stop to it immediately and go back to the old technology that actually works (WCF Web API with FULL OData support which this is supposed to replace and
make easier)
As for your considering of other factors, you list performance. EXACTLY. Any real world application will have AWEFUL PERFORMANCE with this technology.
And while you also list security, that's a non issue because of the nature of linq. Simply filter it on the server side by the l/p from web forms so that no matter the projection it only returns data that is available by security permissions.
Thus this, as usual with MS, comes down to DEADLINES instead of getting a product right. I strongly suggest that instead of rushing half-baked unusable stuff out the door like MS normally does for V1, you push the deadline by a week or two and put in projections
with $select.
(And quite honestly, I don't have a clue why anyone in MS would ever find it acceptable to release a product that is this brutally inefficient and encourages (REQUIRES!) such incredibly bad design that goes DIRECTLY AGAINST your own development guidelines:
Only get the data you absolutely need only when you absolutely need it. Data access is the most expensive part of ANY programming. You can optimize your string commands and loops all day long, but a query to the database will ALWAYS cost more than essentially
every other operation in programming. Thus to REQUIRE that the data fetch be inefficient to start, and then REQUIRE that all of that useless information be sent over the (low speed) wire is rediculous. And given that displaying lists of data is probably 80%
of most applications with CRUD being the other 20% this is the FIRST case you should have optimized, not the last.)
Web API uses OData for most of it's responses. It's the core of the system. Yes you can do things like returning a pure string and even dynamic etc. but the power of the system lies in the ability to page, sort, and
SELECT against your data source.
Any SPA or indeed anyone using WebAPI is going to need projections approximately 80% of the time given that the average project will display lists of data about 80% of the time and CRUD about 20% of the time (Microsoft's own numbers when describing the power
of OData!).
Thus the correct way is to request a projection against a data source that returns the exact information you want from the datasource and nothing else. As I used in my other post, if I want all of the Phone #s of a contact and I want to display only I would
Return Contacts.ID, Contacts.Name, ContactPhoneNumbers.PhoneNo. This results in a small data set that is quick both for the Database Server AND for the transmission over the wire and is memory efficient at every level.
However this is what Microsoft requires with WebAPI in the most common scenario of programming anything hooked up to a database (list data): Select Contacts.*, ContactPhoneNumbers.* FROM Contacts INNER JOIN ContactPhoneNumbers ON Contacts.ContactID = ContactPhoneNumbers.ContactID
Instead of returnning 3 columns of information you've returned every column in both tables. Given that the average contact table will have probably 20-30 columns and the Phone Number table could have 7 or 8, and likely there is a note field on the contact
that will be nvarchar(max) and could have a 2000 word essay written in it in HTML, you've now taken a paged source of 10 records from a few K from the server and over the wire to several hundred times that. Further the more results, the expodentially worse
it gets.
And this doesn't bring up the memory usage issue. The SQL Server has to load all of that data into memory, then WEB API has to load it into memory once from the SERVER and then likely another time to stream it in their json/xml writer implementation. Thus
your web server is going to have memory issues FAST and so will your sql server (any SQL admin seeing what's coming over the wire with Web API will quickly put a stop to it's use for this very reason, to say nothing of the guys paying for your bandwidth and
your customers on less than optimal internet connections who will see a brutally slow app)
Thus MS is making excuses for why they're not supporting the most important operation there is, second only to WHERE when using a database. And the result is going to be crappy, slow applications that don't scale -- Or people simply won't use it.
And yes, this is supposed to be the long term replacement for WCF OData Services (WCF Web API is it's official name and this is just ASP.NET Web API for a reason).
Hence my frustration. I have to use the old, brutally complex WCF Web API for the new project I'm working on because MS won't get their replacement for WCF WEb API right until V3. Then when V3 comes along I'm going to have to completely retool the guts of
our app and likely break our own client implementations AND third parties using our API because MS will have depreciated WCF Web API when they release Version 1 of ASP.NET Web API leaving it the bastard child that will lose functionality support in VS.net
much like they did with WSE when they brought out WCF, even though WCF to this day still doesn't support major parts of WSE several versions later (Shared Secret with encrypted communication without having to have an expensive x509 certificate anyone?).
Same old MS routine. Did it with Linq to SQL, did it with WSE, did it with WinForms (same as VB 6 stuff and thus broken from day one) to WPF To Silverlight, etc. etc. etc: Good implementation of something but gets unwhiedy as versions go by because of the
lack of forsight originally, ditch it for something new, but the something new isn't really done and doesn't really replace the old stuff, but support for the old stuff that actually worked, even if it was brutally complex goes away. Then we're left with busted
stuff that we have to hack to work until MS finally fixes it and puts in all of the stuff they missed the first time, but then the cycle continues.
Wash rinse repeat.
I understand that things evolve over time and you need to adapt and new technologies come along. What I don't understand is MS's ability to accept major breaking issues and push them out the door anyhow because of some timeline. It's the core difference
between Apple and Microsoft. SJ released products when he was good and ready and he liked the results and it worked as intended. Microsoft releases them for beancounters whether or not their ready and work in the scenarios that are clearly required. SJ added
new features that were world changers, not new features that should have obviously been required for the previous version. (i.e. the addition of the app store to iOS back in the day)
Next stop the completely unfinished Windows 8 that breaks the usage of all power users of desktop computers because they are not going to actually address the core issue of replacing the start menu with something that's actually usable in this scenario.
Tech geeks will get pissed off just like they did with Vista, adoption will be horrible on all things other than tablets and maybe laptops because the geeks will tell all of their friends that it sucks and to stay away and MS has another Vista on their hands.
Windows 9 will address this glaring issue that a billion 3rd parties have hacked into the OS and made the OS flaky in the process and tech geeks will like it and it will get wider adoption... if MS hasn't outright lost by that point simply because they think
they need to hit an arbitrary release date instead of making a really great product that really works for the scenarios it's designed for.
Apple is almost a trillion dollar company. Meanwhile Microsoft has 0 growth and 0 increase in stock price as a result since Bill Gates left. This is why and it's too bad.
1. Microsoft's own documentation on SQL Server says that Select * should never be used except in extreme situations because of the performance degradation. (there is even an example of doing an join with select * on both parts of the join as to how aweful
it is on performance)
The support or not of OData's $select has nothing to do with whether the query to the SQL Server uses "select *".
John Galt
2. To do a joined resultset to display a list of say contacts and their phone numbers (pretty common and a common pattern for orders, invoices and just about anything else from a relational database (i.e. ef)) you would have to do a select * on the contacts
that you're returning AND SELECT * ON ALL OF THE PHONE NUMBERS. Versus a projection that would return say ContactID, Name, and the Phone Number from the referenced table. Of course this gets expodentially worse as the size of the resultset goes up, but you
get my drift about the absolutely horrible waste of both bandwidth and processing power.
You as the developer are free to make these choices yourself, using C#/VB code. Supporting $select implies that you want to give that choice to your end users. We discussed this possibility, but for time and security reasons, we aren't planning to ship that
in v1. I suspect the community will probably supplement our IQueryable support to include things like shape-changing with $select.
John Galt
1. Hack it like I am so that the client can control the projections as should be the case.
While I agree that $select can be useful in some cases, I disagree with the characterization that $select is an absolute requirement for every Web API project.
John Galt
2. Write a million methods for every permutation and combination of select query that your site or api request could want in the way of fields.
The majority of the things the users will want to do with a standard Web API will include sorting, paging, and filtering. These operations are all supported.
John Galt
(And quite honestly, I don't have a clue why anyone in MS would ever find it acceptable to release a product that is this brutally inefficient and encourages (REQUIRES!) such incredibly bad design that goes DIRECTLY AGAINST your own development guidelines:
Only get the data you absolutely need only when you absolutely need it. Data access is the most expensive part of ANY programming. You can optimize your string commands and loops all day long, but a query to the database will ALWAYS cost more than essentially
every other operation in programming. Thus to REQUIRE that the data fetch be inefficient to start, and then REQUIRE that all of that useless information be sent over the (low speed) wire is rediculous. And given that displaying lists of data is probably 80%
of most applications with CRUD being the other 20% this is the FIRST case you should have optimized, not the last.)
I'm afraid that I don't understand the point you're making. Queryables create optimized queries already; they do not issue "select *" as you seem to imply they do. Can you provide network traces of cases where standard Entity Framework LINQ queries issue
"select *"?
Web API uses OData for most of it's responses. It's the core of the system. Yes you can do things like returning a pure string and even dynamic etc. but the power of the system lies in the ability to page, sort, and
SELECT against your data source.
This statement is false. Web API supports the OData query syntax, in part, but it does not use OData. Any exposed IQueryable is an implementation detail. Can this be abused? Certainly. The same arguments you make here and elsewhere hold against MVC, as well.
John Galt
Any SPA or indeed anyone using WebAPI is going to need projections approximately 80% of the time given that the average project will display lists of data about 80% of the time and CRUD about 20% of the time (Microsoft's own numbers when describing the power
of OData!).
This still relates to OData, not Web API. It seems you've become confused b/c of the acceptance of the OData query syntax. Web API is not OData. If you want to expose OData directly, you should be using WCF Data Services rather than Web API.
Web API is a tool for you to manage interactions across the HTTP protocol. OData is something else. The query syntax is supported as a convenience. Perhaps it would be more clear if that was an opt-in, perhaps only with full OData support that is yet-to-come.
Would that clear things up more?
John Galt
Thus MS is making excuses for why they're not supporting the most important operation there is, second only to WHERE when using a database. And the result is going to be crappy, slow applications that don't scale -- Or people simply won't use it.
And yes, this is supposed to be the long term replacement for WCF OData Services (WCF Web API is it's official name and this is just ASP.NET Web API for a reason).
No, this is no longer part of WCF, nor is it a long-term replacement for WCF OData Services. Where did you get that? (Or perhaps I'm wrong? Brad? Marcin?) Web API doesn't support OData in the full, so it is in no way a replacement. That's a provably false
assertion.
John Galt
Hence my frustration. I have to use the old, brutally complex WCF Web API for the new project I'm working on because MS won't get their replacement for WCF WEb API right until V3. Then when V3 comes along I'm going to have to completely retool the guts of
our app and likely break our own client implementations AND third parties using our API because MS will have depreciated WCF Web API when they release Version 1 of ASP.NET Web API leaving it the bastard child that will lose functionality support in VS.net
much like they did with WSE when they brought out WCF, even though WCF to this day still doesn't support major parts of WSE several versions later (Shared Secret with encrypted communication without having to have an expensive x509 certificate anyone?).
Same old MS routine. Did it with Linq to SQL, did it with WSE, did it with WinForms (same as VB 6 stuff and thus broken from day one) to WPF To Silverlight, etc. etc. etc: Good implementation of something but gets unwhiedy as versions go by because of the
lack of forsight originally, ditch it for something new, but the something new isn't really done and doesn't really replace the old stuff, but support for the old stuff that actually worked, even if it was brutally complex goes away. Then we're left with busted
stuff that we have to hack to work until MS finally fixes it and puts in all of the stuff they missed the first time, but then the cycle continues.
Wash rinse repeat.
I understand that things evolve over time and you need to adapt and new technologies come along. What I don't understand is MS's ability to accept major breaking issues and push them out the door anyhow because of some timeline. It's the core difference
between Apple and Microsoft. SJ released products when he was good and ready and he liked the results and it worked as intended. Microsoft releases them for beancounters whether or not their ready and work in the scenarios that are clearly required. SJ added
new features that were world changers, not new features that should have obviously been required for the previous version. (i.e. the addition of the app store to iOS back in the day)
Next stop the completely unfinished Windows 8 that breaks the usage of all power users of desktop computers because they are not going to actually address the core issue of replacing the start menu with something that's actually usable in this scenario.
Tech geeks will get pissed off just like they did with Vista, adoption will be horrible on all things other than tablets and maybe laptops because the geeks will tell all of their friends that it sucks and to stay away and MS has another Vista on their hands.
Windows 9 will address this glaring issue that a billion 3rd parties have hacked into the OS and made the OS flaky in the process and tech geeks will like it and it will get wider adoption... if MS hasn't outright lost by that point simply because they think
they need to hit an arbitrary release date instead of making a really great product that really works for the scenarios it's designed for.
Apple is almost a trillion dollar company. Meanwhile Microsoft has 0 growth and 0 increase in stock price as a result since Bill Gates left. This is why and it's too bad.
This is just bad form. I can understand the frustration if your understanding and assertions were accurate, but they aren't. Where did you get the information that Web API was a replacement for WCF Data Services? I think that's the root of the problem. Don't
use Web API. Use WCF Data Services. So far as I'm aware,
that project is alive and well.
Now that I understand the $select notation, you could also create an HttpMessageHandler to control your ObjectContext and manipulate the returned data. Then in your Controller, you could just call the pre-defined query and return the value. At any rate,
HttpMessageHandlers seem a good place for managing creation and disposal of dependencies. This may be a good way to implement full OData support in Web API.
No, this is no longer part of WCF, nor is it a long-term replacement for WCF OData Services. Where did you get that? (Or perhaps I'm wrong? Brad? Marcin?) Web API doesn't support OData in the full, so it is in no way a replacement. That's a provably false
assertion.
You are correct. Web API does not support full OData (just a subset of the query syntax). It is not intended to be a replacement for WCF Data Services.
John Galt
Member
30 Points
47 Posts
Hacking $select into Web API
Mar 26, 2012 08:21 PM|LINK
I really want to use Web API but right now it's broken as in can't ever be used in production broken.
That is that it doesn't support $select so you're always select * and you're always returning full objects. (Amature hour at the zoo!)
So $select is just a parameter on the querystring.
And if I could either bind that to a parameter on the method (can't because of the $ right?) or exclude that parameter and have it still match and just get it from the Request.QueryString then I can use linq dynamic to fix this oversite and just return dynamic.
Then when someone at MS comes to their senses and realizes that this is a bad idea and enables $select it's just a matter of removing the extra method and all of the regular ones will work just fine. (or whatever syntax that they require)
Thoughts on how to do this?
marcind
Contributor
3344 Points
609 Posts
Microsoft
Re: Hacking $select into Web API
Mar 26, 2012 09:26 PM|LINK
I'm not so sure that's true. We considered having that feature but decided not to support in V1 for a variety of reasons.
Unfortunately we have to consider deadlines, costs, performance and/or security considerations as well as the opportunity cost of implementing this instead of any number of other desirable features when prioritizing work. We certainly have this on the list for vNext.
A couple of options. You could use http://msdn.microsoft.com/en-us/library/system.web.http.valueproviders.valueprefixattribute.prefix(v=vs.108).aspx to work around the '$' in the name issue.
Or, you could write a custom http://msdn.microsoft.com/en-us/library/system.web.http.filters.actionfilterattribute(v=vs.108).aspx that could read the query string parameter and dynamically modify the IQueryable content value.
ASP.NET Team
@marcind
Blog
panesofglass
Participant
758 Points
242 Posts
Re: Hacking $select into Web API
Mar 26, 2012 09:30 PM|LINK
I'm sure you and @marcind have some clue about what you are talking about, but I'm totally lost. Is $select some part of the OData query syntax? I have found Web API very useful for production scenarios and hope to roll some items out soon. I also have no love for OData, so that may be why I don't understand any of your points above, if that is how $select relates.
If you are using OData, why not just use OData? How does Web API factor into your platform decision? I'm very confused by your seeming animosity towards the library and the team.
John Galt
Member
30 Points
47 Posts
Re: Hacking $select into Web API
Mar 27, 2012 02:35 PM|LINK
Thanks for the suggestions I will look into them.
However I strongly disagree with your assessment that this isn't an absolute requirement for V1 and that it can be used in production as it is right now:
1. Microsoft's own documentation on SQL Server says that Select * should never be used except in extreme situations because of the performance degradation. (there is even an example of doing an join with select * on both parts of the join as to how aweful it is on performance)
2. To do a joined resultset to display a list of say contacts and their phone numbers (pretty common and a common pattern for orders, invoices and just about anything else from a relational database (i.e. ef)) you would have to do a select * on the contacts that you're returning AND SELECT * ON ALL OF THE PHONE NUMBERS. Versus a projection that would return say ContactID, Name, and the Phone Number from the referenced table. Of course this gets expodentially worse as the size of the resultset goes up, but you get my drift about the absolutely horrible waste of both bandwidth and processing power.
THUS
WebAPI in it's current state leaves one of three choices:
1. Hack it like I am so that the client can control the projections as should be the case.
2. Write a million methods for every permutation and combination of select query that your site or api request could want in the way of fields.
3. Dont' use it and go to something that doesn't force you to write crappy inefficient code. (i.e. the technology that this is supposed to replace!)
Obviously #2 is a non-starter in any large production environment because of the overhead of doing so and the maintainability is almost 0.
Thus unless MS fixes this and adds $select support we're left with hacking it in ourselves. (which is exactly what other people are asking about on stack overflow etc.) or ditiching Web API until some indeterminant point in the future when MS comes to its senses.
You guys need to sit down in a meeting and be real with yourselves and admit that for this to be at all useful and not a typical Microsoft half-baked V1 product that won't be usable until V3, you must have the ability to return projections specified by the consumer. Otherwise you're going to end up with either really crappy slow apps that don't scale and people are going to blame MS for why they're crappy and slow.
and/or
0 uptake on this because any educated database person is going to look at what this is doing and put a stop to it immediately and go back to the old technology that actually works (WCF Web API with FULL OData support which this is supposed to replace and make easier)
As for your considering of other factors, you list performance. EXACTLY. Any real world application will have AWEFUL PERFORMANCE with this technology.
And while you also list security, that's a non issue because of the nature of linq. Simply filter it on the server side by the l/p from web forms so that no matter the projection it only returns data that is available by security permissions.
Thus this, as usual with MS, comes down to DEADLINES instead of getting a product right. I strongly suggest that instead of rushing half-baked unusable stuff out the door like MS normally does for V1, you push the deadline by a week or two and put in projections with $select.
(And quite honestly, I don't have a clue why anyone in MS would ever find it acceptable to release a product that is this brutally inefficient and encourages (REQUIRES!) such incredibly bad design that goes DIRECTLY AGAINST your own development guidelines: Only get the data you absolutely need only when you absolutely need it. Data access is the most expensive part of ANY programming. You can optimize your string commands and loops all day long, but a query to the database will ALWAYS cost more than essentially every other operation in programming. Thus to REQUIRE that the data fetch be inefficient to start, and then REQUIRE that all of that useless information be sent over the (low speed) wire is rediculous. And given that displaying lists of data is probably 80% of most applications with CRUD being the other 20% this is the FIRST case you should have optimized, not the last.)
John Galt
Member
30 Points
47 Posts
Re: Hacking $select into Web API
Mar 27, 2012 03:01 PM|LINK
Web API uses OData for most of it's responses. It's the core of the system. Yes you can do things like returning a pure string and even dynamic etc. but the power of the system lies in the ability to page, sort, and SELECT against your data source.
Any SPA or indeed anyone using WebAPI is going to need projections approximately 80% of the time given that the average project will display lists of data about 80% of the time and CRUD about 20% of the time (Microsoft's own numbers when describing the power of OData!).
Thus the correct way is to request a projection against a data source that returns the exact information you want from the datasource and nothing else. As I used in my other post, if I want all of the Phone #s of a contact and I want to display only I would Return Contacts.ID, Contacts.Name, ContactPhoneNumbers.PhoneNo. This results in a small data set that is quick both for the Database Server AND for the transmission over the wire and is memory efficient at every level.
However this is what Microsoft requires with WebAPI in the most common scenario of programming anything hooked up to a database (list data): Select Contacts.*, ContactPhoneNumbers.* FROM Contacts INNER JOIN ContactPhoneNumbers ON Contacts.ContactID = ContactPhoneNumbers.ContactID
Instead of returnning 3 columns of information you've returned every column in both tables. Given that the average contact table will have probably 20-30 columns and the Phone Number table could have 7 or 8, and likely there is a note field on the contact that will be nvarchar(max) and could have a 2000 word essay written in it in HTML, you've now taken a paged source of 10 records from a few K from the server and over the wire to several hundred times that. Further the more results, the expodentially worse it gets.
And this doesn't bring up the memory usage issue. The SQL Server has to load all of that data into memory, then WEB API has to load it into memory once from the SERVER and then likely another time to stream it in their json/xml writer implementation. Thus your web server is going to have memory issues FAST and so will your sql server (any SQL admin seeing what's coming over the wire with Web API will quickly put a stop to it's use for this very reason, to say nothing of the guys paying for your bandwidth and your customers on less than optimal internet connections who will see a brutally slow app)
Thus MS is making excuses for why they're not supporting the most important operation there is, second only to WHERE when using a database. And the result is going to be crappy, slow applications that don't scale -- Or people simply won't use it.
And yes, this is supposed to be the long term replacement for WCF OData Services (WCF Web API is it's official name and this is just ASP.NET Web API for a reason).
Hence my frustration. I have to use the old, brutally complex WCF Web API for the new project I'm working on because MS won't get their replacement for WCF WEb API right until V3. Then when V3 comes along I'm going to have to completely retool the guts of our app and likely break our own client implementations AND third parties using our API because MS will have depreciated WCF Web API when they release Version 1 of ASP.NET Web API leaving it the bastard child that will lose functionality support in VS.net much like they did with WSE when they brought out WCF, even though WCF to this day still doesn't support major parts of WSE several versions later (Shared Secret with encrypted communication without having to have an expensive x509 certificate anyone?).
Same old MS routine. Did it with Linq to SQL, did it with WSE, did it with WinForms (same as VB 6 stuff and thus broken from day one) to WPF To Silverlight, etc. etc. etc: Good implementation of something but gets unwhiedy as versions go by because of the lack of forsight originally, ditch it for something new, but the something new isn't really done and doesn't really replace the old stuff, but support for the old stuff that actually worked, even if it was brutally complex goes away. Then we're left with busted stuff that we have to hack to work until MS finally fixes it and puts in all of the stuff they missed the first time, but then the cycle continues.
Wash rinse repeat.
I understand that things evolve over time and you need to adapt and new technologies come along. What I don't understand is MS's ability to accept major breaking issues and push them out the door anyhow because of some timeline. It's the core difference between Apple and Microsoft. SJ released products when he was good and ready and he liked the results and it worked as intended. Microsoft releases them for beancounters whether or not their ready and work in the scenarios that are clearly required. SJ added new features that were world changers, not new features that should have obviously been required for the previous version. (i.e. the addition of the app store to iOS back in the day)
Next stop the completely unfinished Windows 8 that breaks the usage of all power users of desktop computers because they are not going to actually address the core issue of replacing the start menu with something that's actually usable in this scenario. Tech geeks will get pissed off just like they did with Vista, adoption will be horrible on all things other than tablets and maybe laptops because the geeks will tell all of their friends that it sucks and to stay away and MS has another Vista on their hands. Windows 9 will address this glaring issue that a billion 3rd parties have hacked into the OS and made the OS flaky in the process and tech geeks will like it and it will get wider adoption... if MS hasn't outright lost by that point simply because they think they need to hit an arbitrary release date instead of making a really great product that really works for the scenarios it's designed for.
Apple is almost a trillion dollar company. Meanwhile Microsoft has 0 growth and 0 increase in stock price as a result since Bill Gates left. This is why and it's too bad.
bradwils
Contributor
5779 Points
691 Posts
Microsoft
Re: Hacking $select into Web API
Mar 27, 2012 03:15 PM|LINK
The support or not of OData's $select has nothing to do with whether the query to the SQL Server uses "select *".
You as the developer are free to make these choices yourself, using C#/VB code. Supporting $select implies that you want to give that choice to your end users. We discussed this possibility, but for time and security reasons, we aren't planning to ship that in v1. I suspect the community will probably supplement our IQueryable support to include things like shape-changing with $select.
While I agree that $select can be useful in some cases, I disagree with the characterization that $select is an absolute requirement for every Web API project.
The majority of the things the users will want to do with a standard Web API will include sorting, paging, and filtering. These operations are all supported.
I'm afraid that I don't understand the point you're making. Queryables create optimized queries already; they do not issue "select *" as you seem to imply they do. Can you provide network traces of cases where standard Entity Framework LINQ queries issue "select *"?
panesofglass
Participant
758 Points
242 Posts
Re: Hacking $select into Web API
Mar 27, 2012 03:47 PM|LINK
This statement is false. Web API supports the OData query syntax, in part, but it does not use OData. Any exposed IQueryable is an implementation detail. Can this be abused? Certainly. The same arguments you make here and elsewhere hold against MVC, as well.
This still relates to OData, not Web API. It seems you've become confused b/c of the acceptance of the OData query syntax. Web API is not OData. If you want to expose OData directly, you should be using WCF Data Services rather than Web API.
Web API is a tool for you to manage interactions across the HTTP protocol. OData is something else. The query syntax is supported as a convenience. Perhaps it would be more clear if that was an opt-in, perhaps only with full OData support that is yet-to-come. Would that clear things up more?
No, this is no longer part of WCF, nor is it a long-term replacement for WCF OData Services. Where did you get that? (Or perhaps I'm wrong? Brad? Marcin?) Web API doesn't support OData in the full, so it is in no way a replacement. That's a provably false assertion.
This is just bad form. I can understand the frustration if your understanding and assertions were accurate, but they aren't. Where did you get the information that Web API was a replacement for WCF Data Services? I think that's the root of the problem. Don't use Web API. Use WCF Data Services. So far as I'm aware, that project is alive and well.
panesofglass
Participant
758 Points
242 Posts
Re: Hacking $select into Web API
Mar 27, 2012 04:18 PM|LINK
Now that I understand the $select notation, you could also create an HttpMessageHandler to control your ObjectContext and manipulate the returned data. Then in your Controller, you could just call the pre-defined query and return the value. At any rate, HttpMessageHandlers seem a good place for managing creation and disposal of dependencies. This may be a good way to implement full OData support in Web API.
bradwils
Contributor
5779 Points
691 Posts
Microsoft
Re: Hacking $select into Web API
Mar 27, 2012 09:11 PM|LINK
You are correct. Web API does not support full OData (just a subset of the query syntax). It is not intended to be a replacement for WCF Data Services.
davebettin
Member
313 Points
94 Posts
Re: Hacking $select into Web API
Mar 28, 2012 04:18 PM|LINK
No more room for complaining anymore. Don't like that a feature is missing? Send a pull request. http://aspnetwebstack.codeplex.com/
@dbettin