Q3 2011 SP1

Nov 30, 2011

Q3 2011 SP1 (version 2011.3.1129)

FIXED
  • Fluent Mapping: Generated column names are incorrectly calculated based on field and not property names. - When using auto-implemented properties, the column name is incorrectly calculated based on the backing field name and not on the property name.
    If a property is defined like 'public string Name { get; set; }' it should have a column named "Name" and not the autogenerated backing field name.
  • Fluent Mapping: A Many-to-Many relationship mapped using 'MapJoinTable(TableName)' now always takes the table name into account - Mapping many-to-many associations using the string overload with a table name depended on the order the mapping configurations were added in the FluentMetadataSource's prepare mappings overload.
  • Fluent Mapping: Many-to-many associations defined with 'MapJoinTable(...)' do not create the correct schema. - When defining associations using 'MapJoinTable(...)' the settings provided are now taken into account and the association is not calculated by the runtime.
  • Attribute Mapping: Foreign Key Associations are not correctly resolved when attributes mapping is used. - If attributes mapping is used, the runtime is always creating default foreign key columns. The shared field information that was previously missing is now correctly stored in the attributes.
  • Attribute Mapping: Custom discriminator columns are not handled by the attributes mapping - If the domain model contains an inheritance hierarchy where custom discriminator columns are used (named differently than "voa_class"), the information is lost, as it is not persisted in the generated attributes.
  • Runtime: Version field not updated after Flush - With the changes in the Flush() implementation, the changed objects were not reloading any data. The server side calculated values and the version field are now updated.
  • Runtime: Using FetchStrategy for collections properties on a class with a composite primary key leads to exception - When a FetchStrategy includes a collection where the primary key of the owner class is composite, a NotSupportedException is thrown when the data is fetched.
  • Runtime: FieldAlias or Storage attribute not resolved when applied to a non-public interface property implementation - When an interface-declared property is implemented non-public in a persistent class, a FieldAlias or Storage attribute is ignored, and LINQ/OQL queries will not find the respective field, throwing an exception.
  • Runtime: Database open can throw ArgumentException - If the customer application catches an exception that the database cannot be opened but continues to use the context, an 'An item with the same key has already been added.' exception can be thrown.
  • ADS: Constraint and Index generation failed for composite keys - When composite keys are used, the index that backs a foreign constraint was not created correctly.
  • LINQ: Using custom collections and .Count / Enumerable.Count() can generate exceptions during translation to SQL - When a custom collection is used as a return type of an aliased property, and the .Count property or Enumerable.Count() extension method is used in a LINQ expression, an IndexOutOfRange exception can be generated.
  • LINQ: InvalidCastException can be thrown when database delivers value that is not IConvertible but result expects different type - When the database delivers a type like SqlDouble, the conversion to an int can fail. Usually this is the result of a cast the was not pushed to the server side; e.g. (int)x.STDistance(y). The int cast is not pushed to the server, but an int is expected by the client and the conversion of the delivered SqlDouble value fails.
  • LINQ: Using enumerable parameters that do not implement ICollection fails with ArgumentOutOfRangeException (Wrong type of instance, expected ...) - When a collection of values is used with Enumerable.Contains<X>(this source, X x), the input parameter of the actual query execution is checked as ICollection, not as IEnumerable. Parameter values that do not implement ICollection can lead to an ArgumentOutOfRangeException. This can happen for results of Enumerable.Where and Enumerable.Select calls, because they do not implement ICollection.
  • LINQ: Improved handling of Cast() expressions - When a LINQ query that looks like
    from Person p in Scope.Extent<Person>() where p.Spouse.Name == "John" select p;
    is used, the superfluous Person type specification leads to a Cast<Person>() expression being generated that will currently force the transition to an in-memory execution, that can lead to a null reference exception.
  • LINQ: Exception thrown when client side boolean equality condition is pushed to the server - When a client side calculable boolean equality condition is pushed to the server, an exception ("Directly parameterized literal boolean eq/neq expression found; use integer type here.") can be thrown during translation of LINQ to SQL.
    Example:
    bool withAge = true;
    var q = from x in context.Persons where x.Age > 42 && withAge == true select x;

Enhancements

  • The OpenAccess project templates are now available for .NET 3.5. - The following project templates are now available in Visual Studio 2010 for creating projects that target the .NET 3.5 framework:
    - Telerik OpenAccess Fluent Library
    - Telerik OpenAccess Class Library
Have a feature request?

Post your feedback via the Data Access feedback portal or the public forums

What's new across all Telerik products?

See the updates feed

Next Steps

Download for free

Get your fully functional free copy of Data Access.

Get Data Access Sample Kit

Including demos and articles to get you started.

Suggest new features

Help us shape our roadmap.