Damien Guard of Microsoft’s Data Programmability has posted a rather long list of the changes to LINQ to SQL. While they are still committed to Entity Framework over the long run, this will do much to alleviate the fear LINQ to SQL will be completely neglected in the mean time.
Performance
- Query plans are reused more often by specifically defining text parameter lengths
- Identity cache lookups for primary key with single result now includes query.Where(predicate).Single/SingleOrDefault/First/FirstOrDefault
- Reduced query execution overhead when DataLoadOptions specified (cache lookup considers DataLoadOptions value equivalency – post beta 1)
Usability
- ITable
interface for additional mocking possibilities - Contains with enums automatically casts to int or string depending on column type
- Associations can now specify non-primary-key columns on the other end of the association for updates
- Support list initialization syntax for queries
- LinqDataSource now supports inherited entities
- LinqDataSource support for Dynamic Data query extenders added
Query stability
- Contains now detects self-referencing IQueryable and doesn't cause a stack overflow
- Skip(0) no longer prevents eager loading
- GetCommand operates within SQL Compact transactions
- Exposing Link
on a property/field is detected and reported correctly - Compiled queries now correctly detect a change in mapping source and throw
- String.StartsWith, EndsWith and Contains now correctly handles ~ in the search string
- Now detects multiple active result sets (MARS) better
- Associations are properly created between entities when using eager loading with Table-Valued Functions (TVFs)
- Queries that contain sub-queries with scalar projections now work better
Update stability
- SubmitChanges no longer silently consumes transaction rollback exceptions
- SubmitChanges deals with timestamps in a change conflict scenario properly
- IsDbGenerated now honors renamed properties that don't match underlying column name
- Server-generated columns and SQL replication/triggers now work instead of throwing SQL exception
General stability
- Binary types equate correctly after deserialization
- EntitySet.ListChanged fired when adding items to an unloaded entity set
- Dispose our connections upon context disposal (ones passed in are untouched)
SQL Metal
- Foreign key property setter now checks all affected associations not just the first
- Improved error handling when primary key type not supported
- Now skips stored procedures containing table-valued parameters instead of aborting process
- Can now be used against connections that use AttachDbFilename syntax
- No longer crashes when unexpected data types are encountered
LINQ to SQL class designer
- Now handles a single anonymously named column in SQL result set
- Improved error message for associations to nullable unique columns
- No longer fails when using clauses are added to the partial user class
- VarChar(1) now correctly maps to string and not char
- Decimal precision and scale are now emitted correctly in the DbType attributes for stored procedures
- Foreign key changes will be picked up when bringing tables back into the designer without a restart
Code generation (SQL Metal + LINQ to SQL class designer)
- Stored procedures using original values now compiles when the entity and context namespaces differ
- Virtual internal now generates correct syntax
- Mapping attributes are now fully qualified to prevent conflicts with user types
- KnownTypeAttributes are now emitted for DataContractSerializer with inheritance
- Delay-loaded foreign keys now have the correct, compilable, code generated
- Using stored procedures with concurrency no longer gets confused if entities in different namespace to context
- ForeignKeyReferenceAlreadyHasValueException is now thrown if any association is loaded not just the first