Zlatko Michailov : Tips

What Do ObjectQuery’s Builder Methods Build

Zlatko Michailov — Wed, 05 Dec 2007 03:26:00 GMT

Until Beta 2 ObjectQuery’s builder methods used to build a Command Tree. There were multiple problems with that:

· Duplicate code - there is already a component that builds Command Trees from Entity SQL.

· Caching – Command Trees are expensive to hash and thus – difficult to cache.

· Tracing – getting a meaningful canonical description of an ObjectQuery required a converting the Command Tree back to text which was a step back.

Therefore, in Beta 2 ObjectQuery was refactored to build Entity SQL internally instead of a Command Tree. When the ObjectQuery is about to be executed, the internal Entity SQL representation is sent to the Entity SQL Parser to build a Command Tree for it. Thus ObjectQuery now leverages the same Query Plan Cache as EntityCommand – queries are compiled only the first time they are executed; subsequent executions reuse the already compiled query plan (as long as the cache is not full).

Reusing the Entity SQL Parser, however, means that ObjectQuery may now surface exceptions from it. That’s not bad as long as there is an API to get to the internal Entity SQL command text. In Beta 2 such an API was missing, but that’s fixed in Beta 3. Similarly to EntityCommand, a CommandText property is exposed now off ObjectQuery.

The same example that showed how to get the native SQL, also shows how to get the Entity SQL for a given ObjectQuery:

// Create an ObjectContext

using (Northwind.Northwind northwind = new Northwind.Northwind(NorthwindConnectionString))

{

// Create an ObjectQuery

ObjectQuery<Northwind.Product> products = northwind.Products

.Where("LEFT(it.ProductName, 1) = 'C'")

.OrderBy("it.ProductName");

// Make sure the connection is open

northwind.Connection.Open();

// Display the Entity SQL built for the ObjectQuery

Console.WriteLine("\n\n---------------------------------------------------------");

Console.WriteLine("Entity SQL");

Console.WriteLine("---------------------------------------------------------");

Console.WriteLine(products.CommandText);

// Display the T-SQL generated for the (Entity SQL of the) ObjectQuery

Console.WriteLine("\n\n---------------------------------------------------------");

Console.WriteLine("T-SQL");

Console.WriteLine("---------------------------------------------------------");

Console.WriteLine(products.ToTraceString());

// Render the result to make sure the query is valid

Console.WriteLine("\n\n---------------------------------------------------------");

Console.WriteLine("Result");

Console.WriteLine("---------------------------------------------------------");

foreach (Northwind.Product product in products)

{

Console.WriteLine("{0,2}: {1}", product.ProductID, product.ProductName);

}

How to Get the Native SQL from an ObjectQuery

Zlatko Michailov — Wed, 05 Dec 2007 02:51:00 GMT

The way to get the native SQL generated for an ObjectQuery is exactly the same as for EntityCommand – using the new ToTraceString() method introduced in Beta 3. Previously that would require a similar (even more obscure) pattern that involved ObjectQuery.CreateCommandTree() and IServiceProvider.CreateCommandDefinition(). Now that there is a new pattern, both of the above methods have been removed from public surface. Yes, that means if you’ve discovered that pattern and you’ve been using it, you have to switch to ToTraceString(). Same rules and restrictions as for EntityCommand apply.

And, here is a sample that shows how to print the native SQL generated for an ObjectQuery:

// Create an ObjectContext

using (Northwind.Northwind northwind = new Northwind.Northwind(NorthwindConnectionString))

{

// Create an ObjectQuery

ObjectQuery<Northwind.Product> products = northwind.Products

.Where("LEFT(it.ProductName, 1) = 'C'")

.OrderBy("it.ProductName");

// Make sure the connection is open

northwind.Connection.Open();

// Display the Entity SQL built for the ObjectQuery

Console.WriteLine("\n\n---------------------------------------------------------");

Console.WriteLine("Entity SQL");

Console.WriteLine("---------------------------------------------------------");

Console.WriteLine(products.CommandText);

// Display the T-SQL generated for the (Entity SQL of the) ObjectQuery

Console.WriteLine("\n\n---------------------------------------------------------");

Console.WriteLine("T-SQL");

Console.WriteLine("---------------------------------------------------------");

Console.WriteLine(products.ToTraceString());

// Render the result to make sure the query is valid

Console.WriteLine("\n\n---------------------------------------------------------");

Console.WriteLine("Result");

Console.WriteLine("---------------------------------------------------------");

foreach (Northwind.Product product in products)

{

Console.WriteLine("{0,2}: {1}", product.ProductID, product.ProductName);

}

How to Get the Native SQL from an EntityCommand

Zlatko Michailov — Wed, 05 Dec 2007 02:31:00 GMT

With the Beta 3 release, Entity Framework is introducing an easy way to get the native SQL from an EntityCommand. There was public API to get to the native SQL, but the pattern was too obscure, and I don’t want to go into detail. Let’s discuss the new one, instead. It’s a single method directly exposed off EntityCommand – ToTraceString(), which returns a string.

There is no guarantee the returned string is directly executable by the provider (although as of today it is for SQL Server). What you should keep in mind is that ToTraceString() requires the associated EntityConnection to be open. On the other hand, ToTraceString() does not require the EntityCommand to be prepared.

Here’s a sample code snippet that shows how to print the native SQL generated for an EntityCommand:

// Create an EntityConnection

using (EntityConnection connection = new EntityConnection(NorthwindConnectionString))

{

string esql = "SELECT VALUE product \n" +

"FROM Northwind.Products AS product\n" +

"WHERE LEFT(product.ProductName, 1) = 'C' \n" +

"ORDER BY product.ProductName";

// Create an EntityCommand for this connection.

EntityCommand productsCmd = connection.CreateCommand();

productsCmd.CommandText = esql;

// Open the connection.

connection.Open();

// Display the Entity SQL text using the CommandText property from DbCommand.

Console.WriteLine("\n\n---------------------------------------------------------");

Console.WriteLine("Entity SQL");

Console.WriteLine("---------------------------------------------------------");

Console.WriteLine(productsCmd.CommandText);

// Display the T-SQL text using the new ToTraceString() method.

Console.WriteLine("\n\n---------------------------------------------------------");

Console.WriteLine("T-SQL");

Console.WriteLine("---------------------------------------------------------");

Console.WriteLine(productsCmd.ToTraceString());

// Traverse and display the result to make sure the query is valid.

Console.WriteLine("\n\n---------------------------------------------------------");

Console.WriteLine("Result");

Console.WriteLine("---------------------------------------------------------");

EntityDataReader productsReader = productsCmd.ExecuteReader(CommandBehavior.SequentialAccess);

while (productsReader.Read())

{

Console.WriteLine("{0,2}: {1}", productsReader.GetInt32(productsReader.GetOrdinal("ProductID")),

productsReader.GetString(productsReader.GetOrdinal("ProductName")));

}

productsReader.Close();

connection.Close();

}

How to Do Custom Mapping Using Entity SQL Views

Zlatko Michailov — Thu, 22 Nov 2007 00:09:00 GMT

This post was intended to be a reply to this question http://forums.microsoft.com/msdn/showpost.aspx?postid=2440161&siteid=1 on the Entity Framework forum, but its size exceeds the forum server limit. Besides, it’s useful in general. So I decided to post it here. In this post you’ll find an entire repro of the subject scenario from the forum.

Create the following database schema:

create table Organization

(

OrganizationId int primary key,

OrganizationName nvarchar(100)

);

create table OrganizationRelationship

(

OrganizationA int foreign key references Organization(OrganizationId),

OrganizationB int foreign key references Organization(OrganizationId),

RelationshipId int

primary key (OrganizationA, OrganizationB, RelationshipId)

);

insert into Organization values(1, 'One');

insert into Organization values(2, 'Two');

insert into Organization values(3, 'Three');

insert into Organization values(4, 'Four');

-- 1: A partner B

-- 2: A client B

-- 3: A subsidiary B

insert into OrganizationRelationship values(1, 2, 1);

insert into OrganizationRelationship values(3, 4, 1);

insert into OrganizationRelationship values(2, 1, 1);

insert into OrganizationRelationship values(4, 3, 1);

insert into OrganizationRelationship values(1, 3, 2);

insert into OrganizationRelationship values(2, 4, 2);

insert into OrganizationRelationship values(1, 4, 3);

insert into OrganizationRelationship values(2, 3, 3);

I ran EdmGen.exe to do a first cut of a model, which I hacked manually afterwards.

CSDL remains virtually unchanged (except some renaming). Notice that it represents the way things are in the database, i.e. the associations match the foreign keys between the two tables:

<?xml version="1.0" encoding="utf-8"?>

</AssociationSet>

</AssociationSet>

</EntityContainer>

<Key>

</Key>

</EntityType>

<Key>

</Key>

</EntityType>

</Principal>

</Dependent>

</ReferentialConstraint>

</Association>

</Principal>

</Dependent>

</ReferentialConstraint>

</Association>

</Schema>

What you have to notice in the MSL is that if you provide a QueryView for one set, all related sets must be given a QueryView. Those are easy to write once you have one. Yesterday I wrote a more complex view than it was need. Also notice that the original associations from SSDL are missing here. That’s because they don’t make sense in the model. Instead, we introduce new associations – Partner, Client, etc. The OrganizationRelationship entity set has also disappeared for the same reason.

<?xml version="1.0" encoding="utf-8"?>

SELECT VALUE Organizations.Organization(org.OrganizationId, org.OrganizationName)

FROM dbo.Organization AS org;

</QueryView>

</EntitySetMapping>

SELECT VALUE Organizations.Partner(

CREATEREF(Organizations.Organization, ROW(rel.OrganizationA)),

CREATEREF(Organizations.Organization, ROW(rel.OrganizationB)) )

FROM dbo.OrganizationRelationship AS rel

WHERE rel.RelationshipId = 1;

</QueryView>

</AssociationSetMapping>

SELECT VALUE Organizations.Client(

CREATEREF(Organizations.Organization, ROW(rel.OrganizationA)),

CREATEREF(Organizations.Organization, ROW(rel.OrganizationB)) )

FROM dbo.OrganizationRelationship AS rel

WHERE rel.RelationshipId = 2;

</QueryView>

</AssociationSetMapping>

</EntityContainerMapping>

</Mapping>

In CSDL we model the sets and types that we already saw in MSL. Additionally, we create navigation properties for each kind of relationship:

<?xml version="1.0" encoding="utf-8"?>

</AssociationSet>

</AssociationSet>

</EntityContainer>

<Key>

</Key>

</EntityType>

</Association>

</Association>

</Schema>

To verify the model I ran the following Entity SQL query:

SELECT org, org.Partners, org.Clients

FROM Organizations.Organization AS org;

-- Powered by eSqlBlast

Which produced the following correct result:

org

Partners

Clients

OrganizationId	OrganizationName
1	One

OrganizationId	OrganizationName
2	Two

OrganizationId	OrganizationName
3	Three

OrganizationId	OrganizationName
2	Two

OrganizationId	OrganizationName
1	One

OrganizationId	OrganizationName
4	Four

OrganizationId	OrganizationName
3	Three

OrganizationId	OrganizationName
4	Four

OrganizationId	OrganizationName
4	Four

OrganizationId	OrganizationName
3	Three

I’m leaving it up to you to expose the Subsidiaries navigation property for homework.

Enjoy!

How to Parse an EntityDataReader

Zlatko Michailov — Sat, 17 Nov 2007 01:31:00 GMT

2007.12.18: Please accept my apologies – today I discovered (and fixed) two bugs in the parsing code. One is a silly error. The other is that collections should be treated as primitive types and refs with regard to the number of fields. The code bellow includes the changes.

2007.12.04: Last week I discovered that the pattern I had listed in this post did not catch unwrapped primitive types and ref’s. So I’m fixing it now. This is the pattern for Beta 3. I see that it could be simplified (in the highlighted sections) if the FieldMetadata collection was populated for non-structural types. I will propose the change for RTM, but there is no guarantee it will be accepted.

Although you can successfully parse an EntityDataReader by only reasoning over its physical shape using record.GetType(i), you cannot reconstruct the entire entity-level structure without using EDM metadata. For instance, you can easily figure that something is coming as a nested DbDataRecord, but you cannot know whether that is an entity type, a complex type, or a row type. To get the exact entity-level structure, EDM metadata must be used.

Following is an extraction from a class that “visits” an arbitrary EntityDataReader. The highlighted portion is the place where the EDM metadata is obtained.

// We want to make sure the passed DbDataReader

// is actually an EntityDataReader.

public void VisitReader(EntityDataReader reader)

{

VisitReader_(reader);

}

// Nested collections are assembled as internal BridgeDataReader’s.

// That’s why we can’t reuse the public method.

private void VisitReader_(DbDataReader reader)

{

while (reader.Read())

{

// We’ll call this method with internal BridgeDataReader’s

// that implement IExtendedDataRecord.

VisitRecord_(reader as IExtendedDataRecord);

}

// The metadata is exposed through IExtendedDataRecord.

private void VisitRecord_(IExtendedDataRecord record)

{

// First get the type kind of the record itself.

// A record is not necessarily a strucutral type.

BuiltInTypeKind recordTypeKind = record.DataRecordInfo.RecordType.EdmType.BuiltInTypeKind;

int fieldCount;

// For RefType, PrimitiveType, and CollectionType the FieldMetadata collection is not populated.

// In those cases the record contains exactly one field.

if (recordTypeKind == BuiltInTypeKind.RefType ||

recordTypeKind == BuiltInTypeKind.PrimitiveType ||

recordTypeKind == BuiltInTypeKind.CollectionType)

{

fieldCount = 1;

}

else

{

fieldCount = record.DataRecordInfo.FieldMetadata.Count;

}

for (int i = 0; i < fieldCount; i++)

{

// If the field is flagged as DbNull, the shape of the value is undetermined.

// An attempt to get such a value may trigger an exception.

if (record.IsDBNull(i))

{

// ... (Render NULL)

}

else

{

BuiltInTypeKind fieldTypeKind = recordTypeKind;

// If the record is a structural type, examine the field with the given index.

if (fieldTypeKind == BuiltInTypeKind.EntityType ||

fieldTypeKind == BuiltInTypeKind.ComplexType ||

fieldTypeKind == BuiltInTypeKind.RowType)

{

fieldTypeKind = record.DataRecordInfo.FieldMetadata[i].FieldType.TypeUsage.EdmType.BuiltInTypeKind;

}

switch (fieldTypeKind)

{

case BuiltInTypeKind.CollectionType:

// Collections are surfaced as nested BridgeDataReader’s.

VisitReader_(record.GetData(i));

break;

case BuiltInTypeKind.EntityType:

// Entities are wrapped in BridgeDataRecord’s.

VisitRecord_(record.GetDataRecord(i) as IExtendedDataRecord);

break;

case BuiltInTypeKind.ComplexType:

// Complex type instances are wrapped in BridgeDataRecord’s.

VisitRecord_(record.GetDataRecord(i) as IExtendedDataRecord);

break;

case BuiltInTypeKind.RowType:

// Row instances are wrapped in BridgeDataRecord’s.

VisitRecord_(record.GetDataRecord(i) as IExtendedDataRecord);

break;

case BuiltInTypeKind.RefType:

// Ref’s are surfaced as EntityKey instances. The containing record sees them as atomic.

VisitKey_(record.GetValue(i) as EntityKey);

break;

case BuiltInTypeKind.PrimitiveType:

// Primitive types are surfaced as plain objects.

// ... (Render record.GetValue(i).ToString())

break;

default:

// Unhandled type kind. We shouldn't end up here.

// ... (Render fieldTypecand.ToString())

break;

}

private void VisitKey_(EntityKey key)

{

// ... (Render key.EntitySetName)

foreach (EntityKeyMember keyMember in key.EntityKeyValues)

{

// ... (Render keyMember.Key)

// ... (Render keyMember.Value)

}

The code above uses the following namespaces:

using System.Data;

using System.Data.Common;

using System.Data.EntityClient;

using System.Data.Metadata;

using System.Data.Metadata.Edm;

XSL Transformation of CSDL into HTML

Zlatko Michailov — Fri, 16 Nov 2007 23:18:00 GMT

The attached XSL script neatly renders an Entity Framework CSDL file into HTML.

Below is the NorthwindEF model that we’ve been using for our samples, rendered using that XSL script:

Northwind

Entity Sets
Entity Types
Complex Types
Associations

Entity Sets

Northwind
Employees	Northwind.Employee
Territories	Northwind.Territory
Regions	Northwind.Region
Suppliers	Northwind.Supplier
Products	Northwind.Product
Categories	Northwind.Category
Customers	Northwind.Customer
Orders	Northwind.Order
OrderDetails	Northwind.OrderDetail

Entity Types

Order
OrderID	Int32
EmployeeID	Int32
OrderDate	DateTime
RequiredDate	DateTime
ShippedDate	DateTime
Freight	Decimal
ShipName	String
ShipAddress	String
ShipCity	String
ShipRegion	String
ShipPostalCode	String
ShipCountry	String
Customer	Northwind.CustomerOrders
OrderDetails	Northwind.Order_Details_Order

InternationalOrder
Northwind.Order
CustomsDescription	String
ExciseTax	Decimal

Employee
EmployeeID	Int32
LastName	String
FirstName	String
Title	String
TitleOfCourtesy	String
BirthDate	DateTime
HireDate	DateTime
Address	Northwind.CommonAddress
HomePhone	String
Extension	String
Photo	Binary
Notes	String
PhotoPath	String
Territories	Northwind.EmployeesTerritories

CurrentEmployee

Northwind.Employee

PreviousEmployee

Northwind.Employee

Product
ProductID	Int32
ProductName	String
QuantityPerUnit	String
UnitPrice	Decimal
UnitsInStock	Int16
UnitsOnOrder	Int16
ReorderLevel	Int16
Category	Northwind.Products_Category
OrderDetails	Northwind.Order_Details_Product
Supplier	Northwind.Products_Supplier

DiscontinuedProduct
Northwind.Product
DiscontinuedDate	DateTime

Customer
CustomerID	String
CompanyName	String
ContactName	String
ContactTitle	String
Address	Northwind.CommonAddress
Phone	String
Fax	String
Orders	Northwind.CustomerOrders

Category
CategoryID	Int32
CategoryName	String
Description	String
Picture	Binary
Products	Northwind.Products_Category

Supplier
SupplierID	Int32
CompanyName	String
ContactName	String
ContactTitle	String
Address	Northwind.CommonAddress
Phone	String
Fax	String
HomePage	String
Products	Northwind.Products_Supplier

OrderDetail
OrderID	Int32
ProductID	Int32
UnitPrice	Decimal
Quantity	Int16
Discount	Single
Order	Northwind.Order_Details_Order
Product	Northwind.Order_Details_Product

Territory
TerritoryID	Int32
TerritoryDescription	String

Region
RegionID	Int32
RegionDescription	String

Complex Types

CommonAddress
Address	String
City	String
Region	String
PostalCode	String
Country	String

Associations

CustomerOrders
Customer	Northwind.Customer	0..1
Orders	Northwind.Order	*

Products_Category
Category	Northwind.Category	0..1
Products	Northwind.Product	*

Products_Supplier
Supplier	Northwind.Supplier	0..1
Products	Northwind.Product	*

Order_Details_Product
Product	Northwind.Product	1
OrderDetails	Northwind.OrderDetail	*

Order_Details_Order
Order	Northwind.Order	1
OrderDetails	Northwind.OrderDetail	*

EmployeesTerritories
Employees	Northwind.Employee	*
Territories	Northwind.Territory	*

TerritoriesRegion
Region	Northwind.Region	1
Territories	Northwind.Territory	*

Entity SQL Tip #1

Zlatko Michailov — Thu, 01 Nov 2007 21:36:00 GMT

A well defined query against a well defined entity data model does not need JOIN.

Navigation properties in combination with nesting sub-queries should be used instead. These latter constructs represent task requirements much more closely than JOIN does. That makes it easier to build and maintain correct Entity SQL queries.