OakLeaf Systems: Using the Entity Framework with IronPython 1.1 in Project Jasper

Friday, May 11, 2007

Using the Entity Framework with IronPython 1.1 in Project Jasper

Andrew Conrad's A walk through the Jasper API with IronPython - Part 1 post shows you how to get Project Jasper running with IronPython 1.1. I'm far from a Python expert, so I thought I'd give Andrew's step-by-step instructions a test drive. Here's what I did:

Setup

Downloaded Jasper: MIX 2007 CTP release (MicrosoftJasperCTP.msi, 14.0 MB) and installed it on my test machine that runs the prerequisite Orcas Beta 1 and an SQL Express instance with the Northwind sample database installed.
Downloaded the IronPython 1.1 runtime binary from CodePlex (IronPython-1.1-Bin.zip, 973 KB) and expanded it to my \Program Files folder with the Use Folder Names checkbox marked. Installing IronPython 1.1 adds an ...\IronPython-1.1 folder with \Doc, \Lib, and \Tutorial folders.
Ran ipy.exe -X:TabCompletion from a command prompt to open the interactive console. (There's also an ipyw.exe that runs IronPython without a console.)
Changed ipy.exe's default background color to R=222, G=112 and B=8 and text color to R=245, G=222, and B=179 to match my blog colors.

Obtaining a DynamicContext

Typed clr.AddReferenceToFileAndPath("C:\\Program Files\\Microsoft Codename Jasper CTP\\Binaries\\Microsoft.Jasper.CTP.dll") to add the Jasper reference.
Typed the Microsoft.Jasper import * directive.
Typed connString = "Provider='System.Data.SqlClient';Provider Connection String='Initial Catalog=Northwind;Data Source=.\SQLEXPRESS;Integrated Security=SSPI';Generate Default EDM=True" to create the connectionString variable.
Typed nw = DynamicContext.CreateDynamicContext(connString) to create a DynamicContext object for the Northwind sample database. It took about 13 seconds to generate the default Entity Data Model (EDM) for the Northwind tables and associations. This is about half the approximately 30 seconds it took to in Sam Drucker and Shyam Pather's DEV18 - Rapidly Building Data Driven Web Pages with Dynamic ADO.NET MIX07 video (19:17 to 19:47).

Note: All instructions must be entered at the console's >>> prompt as a single line of text. The complete connection string doesn't appear in Andy's post (even in 1280 x 960 resolution) and needs to be changed if you're running SQL Server Express.

At this point, I was ready to exercise the DynamicContext object:

Spelunking the DynamicContext Object

To prove that the ObjectContext's entity sets were collections of the Query type, I typed print type[nw.Products], which returned Query. I then went on to test a few more of Andy's examples. I noticed a brief delay when assigning a new Query collection member to a variable with statements such as product = nw.Products[0] or category = product.Category. Associations are navigable as shown in the last two queries.

Querying with Entity SQL

Entity SQL (eSQL) is the second approach to querying objects exposed by DynamicContext:

If IntelliSense was enabled in the console, as implied in Andy's post, it didn't work for me.

Supporting LINQ in Jasper

LINQ is Jasper's third query technology. Unfortunately, Jasper doesn't support LINQ to Entities currently. In response to a question in the Project Codename: Jasper forum, Carl Perry said the following:

We do support LINQ in this CTP release of Jasper, however only LINQ to Objects is supported. While we were working on this CTP we did work to have our dynamically generated classes and collections support LINQ; essentially providing the ability to translate LINQ queries to the backend query language. This support is available to in the Entity Framework in the form of LINQ to Entities. Unfortunately, due to limitations in VB.NET 9.0 and Iron Python 1.1, we were unable to support translation of these LINQ queries to appropriate backend query language. Supporting LINQ in our dynamic languages (VB.NET, Iron Python, Iron Ruby, etc) is extremely important and we are currently working with teams across the company to get this working. [Minor corrections made.]

Andy Conrad further clarifies the LINQ support situation in response to a Jasper forum rant against VB:

I would suggest that folks give VB a chance occasionally. IMHO, particularly with the new features coming on line in VB9 (lambda expressions, LINQ) and beyond (true dynamism) I think VB is becoming a very compelling dynamic language. And based on constantly switching between languages while working on Jasper, between Python, Ruby, and VB – I can’t say I can pick one over the others.

That said, the DLR will initially support four different .NET languages (IronRuby, IronPython, VBX, and managed Javascript) and we are designing the Jasper framework to work in all, so the developer will be free to pick their dynamic language of choice.
A couple of clarifications – Linq is supported by IronPython 2.0 but not IronPython 1.1. Since the initial CTP of Project Jasper is not integrated with the DLR, we only support VB 9 and Iron Python 1.1 – and only the former supports Linq.
Also, Project Jasper CTP is built on top of .NET framework 3.5 Beta 1 (Orcas release). We could have built it over .NET framework 2.0, but we wanted Linq support. As I said before, as on the next CTP release Jasper will be built over the DLR which is targeted as a post Orcas release.

The Project Jasper CTP download includes VB and IronPython 1.1 samples in the \Program Files\Microsoft Code Name Jasper\Samples folder. If you're running Vista, you must move the samples outside the \Program Files folder.

Update 5/12/2007: Andy Conrad's Some comments about comments and other ramblings about Project Jasper post of May 11, 2007 explores developers' unease with frameworks and scaffolding that substitute built-in processes for programmer-authored code. (I find myself a bit uncomfortable not having direct control of the database connection when using DataContext or DynamicContext objects.) However, this perceived lack of developer control certainly hasn't impeded widespread adoption of Ruby on Rails and ActiveRecord for projects similar to those that Jasper appears to target.

Andy links to a secretGeek post that takes Microsoft to task for 1) not recognizing the contributions of others to dynamic languages and the convention over configuration concept (specifically David Heinemeier Hansson, the original developer of Ruby on Rails, and 2) limiting Jasper to SQL Server 2005 databases only.

Credit Where Credit is Due

I don't fault Microsoft for not thanking Hansson by name any more than I'd complain that download pages for SQL Server 2005 don't include "thanks to Dr. E. F. Codd for his contributions to relational database theory and design." (It's clear to me that Blinq was inspired by Ruby on Rails scaffolding, and I inferred this in my June 2006 Generate Data-Based Web Sites With Blinq post and Visual Studio Magazine article about Polita Paulus's original Bling implementation. Blinq was based on LINQ to SQL, not the Entity Data Model.)

RDBMS Xenophobia in Project Jasper and Related Technologies

I do agree with secretGeek and the post's commenters that restricting Jasper to SQL Server is a bad idea, just as bad as—or worse than—doing the same to LINQ to SQL (see my Future LINQ to SQL Support for Multiple Databases? post of April 19, 2007). Microsoft touts the Entity Framework as accommodating databases other than SQL Server 200x if the RDBMS vendor is willing to invest in writing an EntityClient data provider. In a 4/21/2007 update to that post I noted that Microsoft held an on-campus seminar to aid other RDBMS vendors in extending their .NET data providers with EntityClient features. IBM, for one, says it intends to support LINQ, presumably via the Entity Framework.

If Microsoft intends to live up to its commitment that a primary feature of the Entity Framework is "The ability to query relational stores other than the Microsoft SQL Server family of products" it behooves the ADO.NET team to extend this capability to Entity Framework derivatives, such as Jasper and Astoria (which also has an SQL Server 2005 requirement for the toolkit). Microsoft must clarify that the SQL Server 2005-only limitation applies only to the early "incubator project" releases and not to the final release, if there is one. Failing that is "crying wolf"—no developer or RDBMS vendor will believe that the Entity Framework will be RDBMS-agnostic when Microsoft says Katmai will deliver the Entity Data Platform.

Update 5/22/2007: Andy's response to my comment in his Some comments about comments and other ramblings about Project Jasper post clarifies that Astoria's and Jasper's SQL Server-only restriction is a temporary expedient to get the samples "out the door." Here's the part of the response relating to database agnosticism:

Jasper being a Sql Server only framework is just a limitation of the first CTP. If you look at the Jasper download package, we install private copies of System.Data.dll and System.Data.Entity.dll (renamed for the CTP) because we required some Entity Framework functionality not available in the Beta 1 Orcas down load. As a result, because of the ADO.net provider factory design and the fact we didn’t want to mess with config files – we decided to hard code Sql Client as the only provider for the initial CTP. This was a hard decision, but we wanted to get the preview out the door. And since Sql Express is free – we could at least give folks a chance to play around with Jasper. In house we actually have had Jasper working over some of the non-Sql Server Entity Framework providers and even over Access and DataSets. Non-Sql Server provider support is very high on our list for CTP2.

Also of note, Katmai (next version of Sql Server) for the Entity Framework is a ship vehicle not a restriction on what providers are supported. Astoria and Jasper are currently very early in the product cycle (still in incubation) but I don’t see any reason why these technologies would only support Sql Server. [Emphasis added.]

Hopefully, Katmai won't be the only ship vehicle for the Entity Framework.