talktopete (2) [Avatar] Offline
Hi all and thanks for your reply in advance.
I've been "kicking the tires" of the new linq technology to evaluate its power as an ORM vs NHibernate.
Instead of working with code generators, I prefer to separate my objects from their relational mapping and avoid code generators as much as possible, for numerous reasons.
Following some various examples, used SqlMetal.exe to generate the following xml file:

<?xml version="1.0" encoding="utf-16"?>
<Database Name="SalesDB" xmlns="">
<Table Name="dbo.OrderItems" Member="OrderItems">
<Type Name="OrderItems">
<Column Name="OrderItemID" Type="System.Int32" DbType="Int NOT NULL IDENTITY" IsPrimaryKey="true" IsDbGenerated="true" CanBeNull="false" />
<Column Name="SalesOrderID" Type="System.Int32" DbType="Int NOT NULL" CanBeNull="false" />
<Column Name="SalesItemID" Type="System.Int32" DbType="Int NOT NULL" CanBeNull="false" />
<Column Name="Quantity" Type="System.Int32" DbType="Int NOT NULL" CanBeNull="false" />
<Association Name="FK_OrderItems_SalesItems" Member="SalesItems" ThisKey="SalesItemID" Type="SalesItems" IsForeignKey="true" />
<Association Name="FK_OrderItems_SalesOrders" Member="SalesOrders" ThisKey="SalesOrderID" Type="SalesOrders" IsForeignKey="true" />
<Table Name="dbo.SalesItems" Member="SalesItems">
<Type Name="SalesItems">
<Column Name="SalesItemID" Type="System.Int32" DbType="Int NOT NULL IDENTITY" IsPrimaryKey="true" IsDbGenerated="true" CanBeNull="false" />
<Column Name="SalesItemTypeID" Type="System.Int16" DbType="SmallInt NOT NULL" CanBeNull="false" />
<Column Name="Sku" Type="System.String" DbType="VarChar(255) NOT NULL" CanBeNull="false" />
<Column Name="Price" Type="System.Decimal" DbType="Money NOT NULL" CanBeNull="false" />
<Column Name="PageCount" Type="System.Int32" DbType="Int" CanBeNull="true" />
<Column Name="NumberOfMinutes" Type="System.Int32" DbType="Int" CanBeNull="true" />
<Association Name="FK_OrderItems_SalesItems" Member="OrderItems" OtherKey="SalesItemID" Type="OrderItems" DeleteRule="NO ACTION" />
<Table Name="dbo.SalesOrders" Member="SalesOrders">
<Type Name="SalesOrders">
<Column Name="SalesOrderID" Type="System.Int32" DbType="Int NOT NULL IDENTITY" IsPrimaryKey="true" IsDbGenerated="true" CanBeNull="false" />
<Column Name="SalesOrderKey" Type="System.String" DbType="VarChar(255) NOT NULL" CanBeNull="false" />
<Association Name="FK_OrderItems_SalesOrders" Member="OrderItems" OtherKey="SalesOrderID" Type="OrderItems" DeleteRule="NO ACTION" />

I saved this as a MasterDBMappings.xml file as an embedded resource in my project.
I use the following code to load the mappings into a datacontext:

XmlMappingSource mapping;
using (Stream stream = Assembly.GetExecutingAssembly().GetManifestResourceStream("DLinqEntityLayer02.MasterDBMappings.xml"))
mapping = XmlMappingSource.FromStream(stream);
databaseContext = new DatabaseContext("initial catalog='SalesDB';server=localhost;user id =sa;password=****;",mapping);

I get the following exception and I am very confused:

TestFixture failed: System.Xml.Schema.XmlSchemaException : Database node not found. Is the mapping namespace ( correctly specified?

now a quick search through google implies that my xml schema is out of date. If I use the sqlmetal.exe that comes with the .NET 3.5 framework, and the project is a .net 3.5 build, how can this be possible?
fabrice.marguerie (224) [Avatar] Offline
Re: Manual DataContext building woes...
Hi Peter,

As far as I can tell, the XML schema used in your file is the same as in the dbml files I generate with my version (3.5 Beta 2) of SqlMetal.exe and the LINQ or SQL designer:
The fact that your program is asking for another schema ( makes it look as if you are using an old version of the System.Data.Linq.dll assembly. Maybe you should check which version of this assembly is loaded or referenced by your application, and where it comes from?
If this does not prove to be the problem, maybe it's an encoding problem, as suggested by Matt Warren in the following thread:

Please, let us know what you find.

talktopete (2) [Avatar] Offline
Re: Manual DataContext building woes...
Fabrice thank you for your advice.
you were correct. somehow the xml schema was lost in translation.
It seems there is a difference between a mapping file (map output in sqlmetal) and dbml file they are not the same thing but their information seems to be redundant, this is a point of confusion at the moment.

I am still researching a technical comparison between linq and NHibernate. I have two parallel solutions that work with a common schema. this schema has many-to-one associations and inheritance.

I understand that the main attraction to linq is the powerful querying syntax, but I am experimenting its performance in an "active record design pattern" orm implementation. For this to be a good implementation there has to be some features for object versioning (DataContext has this), cascade delete/update (linq has this through user-defined events) and eager/lazy fetching of associations. My hope is to come up with a feature-by-feature comparison of linq and NHibernate.

My current impression is that linq is not a direct competitor to NHibernate: NHibernate was designed for ORM-related problems, and linq is "accidentally" an orm simply by the definition of its feature set. I imagine it would not be difficult to make a linq-based framework as a true ORM, but there are currently certain important features missing in this aspect (perhaps I have not yet found them).

anyways thank you for your help and I will continue my search.
fabrice.marguerie (224) [Avatar] Offline
Re: Manual DataContext building woes...

You are right. In a sense, LINQ to SQL competes with NHibernate. However, the real competitor to NHibernate will be the ADO.NET Entity Framework. It will offer more features than LINQ to SQL and support for more databases than just SQL Server. It will also support LINQ, through LINQ to Entities.
In addition, one can query NHibernate with LINQ. Some work has been started to create something like LINQ to NHibernate. See here:

jwooley (123) [Avatar] Offline
Re: Manual DataContext building woes...
Pete, I ran into this issue repeatedly when working between the various versions of the beta cycle. As each new release came out, I had to fight the same thing. One of the early changes regarded the XML Namespace. In addition, prior to Beta 2, SQL Metal and the LINQ to SQL designer used slightly different engines under the covers and produced incompatible results at times.

The fun is not yet over. Be aware that when the final release comes out, you may need to change your XML to use encoding="utf=8" rather than utf-16.

I'm glad you were able to get this figured out and reported your findings.