About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
Community comments
Not able to load Video
by Ajay Bhosale /
Code Samples
by Ajay Bhosale /
It doesn't have to be IQueryable
by Stefan Wenig /
Re: It doesn't have to be IQueryable
by Stefan Wenig /
Not able to load Video
by Ajay Bhosale /
Your message is awaiting moderation. Thank you for participating in the discussion.
16:04:44:884 NetConnection.Connect.Success ( rtmpe://sxrl3x941kr4c.cloudfront.net/cfx/st/ ) 16:04:48:568 NetStream.Play.StreamNotFound ( x.mp4 )
16:04:48:570 NetConnection.Connect.Closed
16:04:48:577 MediaPlayer.Error.FAILED TO PLAY X.MP4; STREAM NOT FOUND.
16:04:48:578 NetStream.Play.Stop ( x.mp4 )
Code Samples
by Ajay Bhosale /
Your message is awaiting moderation. Thank you for participating in the discussion.
Does the code samples available for download?
It doesn't have to be IQueryable
by Stefan Wenig /
Your message is awaiting moderation. Thank you for participating in the discussion.
Bart seems to imply that if you hand-code your query classes without implementing IQueryable, you can limit the power of LINQ queries at compile-time to whatever you want to implement in your LINQ provider. That would indeed be cool.
However, beyond the simple scenarios he shows there's little chance to get there. Take an O/R mapper, the most common scenario for LINQ providers. When we want to use our POCO classes for queries, we're out of luck here. Even if our query factory returns a MyQueryable<MyType> that does not implement IQueryable<MyType>, MyType will likely have members that implement IEnumerable<T>, and now any LINQ expression using these members will be compiled. Unsupported features will just break at runtime, and there's nothing you can do about it.
The consequence is that any useful LINQ provider needs to implement almost anything, or it will be useless because nobody wants to guess what's possible and then try it out and re-write it until it works. A complete LINQ provider is much harder to write than one that supports, say, 80% of query features. And there's alyways stuff that can _only_ be executed in memory (basically any user-defined method, comparers etc.)
We spent some time figuring out how we could add compile-time limitations to LINQ provider toolkit (relinq.codeplex.com), but it just doesn't work without generating specific queryable classes for any classes participating in queries. Which in turn would not only mess up the build process, but also create circular dependencies whenever you want to write a LINQ query in a queryable class.</t></mytype></mytype>
Re: It doesn't have to be IQueryable
by Stefan Wenig /
Your message is awaiting moderation. Thank you for participating in the discussion.
InfoQ's comment system still has this encoding problem that leads to XML closing tags for generics...