Most of my posts have been about what is new in beta2 or RTM or how you can do great things with feature X and how bug Y has been fixed. Now that we are practically done with V1, it is time to do the somewhat unpleasant task of saying – sorry, this is not in V1.
A lot of you have been very generous with your suggestions, feedback etc. In each case, we heard you, we (or at least I) am convinced of the merit of your suggestion. However, in the end, the limits of calendar and resources have played their part as have our own failings in what you might consider incorrect prioritization. This is necessarily a partial list based on frequency/strength of the feedback and consistency with what LINQ to SQL was designed for. I wanted to pick a small set of common ones.
- Support for other databases with or without a public provider model. Yes, we know that there are plenty of IT shops with more than SQL Server and for you ISVs and SIs, a broader bet is important.
- Out-of-the-box multi-tier story. Yes, we do have good Attach() APIs but we don’t yet have a simple roundtripping and change tracking on the client. (I hope to work on some of these parts on my next project 🙂 )
- Handling schema changes. Schemas change and designer and SqlMetal should provide reasonable ways to respond to the changes.
- Support for specific mappings: containment (e.g. Address is a non-entity type and should be mappable differently for Customer.Address vs Employee.Address), pure many-to-many with no non-FK data in the middle table.
- Small differences between designer, SqlMetal and run-time: external mapping file and SSC support in designer
- LINQ to SQL in compact framework
Beyond V1, it is community’s feedback that will help shape the direction. On that note, I am handing over the LINQ to SQL Program Management mantle to Tim Mallalieu in the SQL-DP team. I have moved to another project with the developer division at Microsoft (more about that on a sunny day).
If you think I missed something huge that should be in top 6 above, please post!