Friday, 14 March 2008

This is so not agile.

I have a namespace: EntityFrameworkContrib.PostSharp4EF.Testing.ComplexType and a testclass: ComplexTypeTest.
When I call to EntityFramework it apparently wants to log something and fails because of a 127 category name limit: Instance names used for writing to custom counters must be 127 characters or less.

This is shown in the callstack:

System.dll!System.Diagnostics.SharedPerformanceCounter.SharedPerformanceCounter(string catName, string counterName = "numberofactiveconnectionpoolgroups", string instanceName = "unittestadapterdomain_forg:_dev_efcontrib_entityframeworkcontrib.postsharp4ef_testresults_shrtrun[18]_out_entityframeworkcontrib.postsharp4ef.testing.dll[12116]", System.Diagnostics.PerformanceCounterInstanceLifetime lifetime = Process) + 0xcc bytes   

You can see I've already made a 'shrtrun' name for the tests, instead of the long generated name. That was suggested on a few forums: the name generated by the testframework is very long and can be shortened. That might help you:

Go to Test/Edit Testrun configuration

However, no way does that help enough on my end.
I believe I read that this was a bug that they would fix in 2008, but it's still there.

Does that mean I should shorten my namespaces? I don't really feel like it, since I believe in clear names. One of the contributors of EFContrib even suggested writing contrib as contribution!

My current workaround is a console application that tests the code that I'm working on, but I need to build out tests now.

Anybody know any real workarounds?

Friday, 14 March 2008 18:25:22 (Romance Standard Time, UTC+01:00)  #    Comments [10]  |  Trackback

I just finished full support for using complex types in EFContrib. I thought I'd quickly share what complex types are and how they are used in Entity Framework.

Julie Lerman blogged about Complex Types here, where she also shows how to use them. Check her post for a great example.
In Daniel Simmons' words:
Complex types “Complex types” is the Entity Framework name for value properties which have more intricate structure than scalars. The canonical example is an Address type which contains several parts (street, city, state, etc.) Complex types are somewhat like entities except that they do not have any identity of their own (they are value types). This means that a complex type instance is always a part of some other enclosing entity—it can’t stand on its own, it doesn’t have relationships, etc. In this release, the mapping scenarios for complex types are significantly limited: inheritance is not supported, complex type properties cannot be null and they can only occur in single instances, not collections.

So, a complex type can be seen as a struct, without identity.
Let's create a complex type. I will have a person table with 3 address related columns. My person object though, should have a property named 'Address' which points to a class of type Address.
The CSDL looks like this:

        <EntityType Name="Person">
            <PropertyRef Name="PersonID" />
          <Property Name="PersonID" Type="Int32" Nullable="false" />
          <Property Name="FirstName" Type="String" Nullable="false" MaxLength="50" Unicode="false" />
          <Property Name="LastName" Type="String" Nullable="false" MaxLength="50" Unicode="false" />
          <Property Name="Address" Type="Self.Address" Nullable="false" />
        <ComplexType Name="Address">
          <Property Name="City" Type="String" Nullable="false" MaxLength="50" Unicode="false" />
          <Property Name="Street" Type="String" Nullable="false" MaxLength="50" Unicode="false" />
          <Property Name="PostalCode" Type="String" Nullable="false" MaxLength="10" Unicode="false" />

Pretty clear: our Person has an address property, with a type of 'Self.Address'. Make sure it is not Nullable. The Address is defined just like you would expect. Please know that the current designer does not allow designing complextypes visually, which is why I did it in xml.

The database looks like this:

        <EntityContainer Name="dbo">
          <EntitySet Name="Person" EntityType="ComplexTypesTestModel.Store.Person" />
        <EntityType Name="Person">
            <PropertyRef Name="PersonID" />
          <Property Name="PersonID" Type="int" Nullable="false"  StoreGeneratedPattern="Identity" />
          <Property Name="FirstName" Type="varchar" Nullable="false" MaxLength="50" />
          <Property Name="LastName" Type="varchar" Nullable="false" MaxLength="50" />
          <Property Name="Street" Type="varchar" Nullable="false" MaxLength="50" />
          <Property Name="City" Type="varchar" Nullable="false" MaxLength="50" />
          <Property Name="PostalCode" Type="varchar" Nullable="false" MaxLength="10" />

Here we see a row with all columns in it. Darned DBA's!!

To map that database description to the classes, we take a look at the C-S mapping:

          <EntitySetMapping Name="Person">
            <EntityTypeMapping TypeName="IsTypeOf(EntityFrameworkContrib.PostSharp4EF.Testing.ComplexType.Person)">
              <MappingFragment StoreEntitySet="Person">
                <ScalarProperty Name="PersonID" ColumnName="PersonID" />
                <ScalarProperty Name="FirstName" ColumnName="FirstName" />
                <ScalarProperty Name="LastName" ColumnName="LastName" />
                <ComplexProperty Name="Address">
                  <ScalarProperty Name="City" ColumnName="City"/>
                  <ScalarProperty Name="Street" ColumnName="Street"/>
                  <ScalarProperty Name="PostalCode" ColumnName="PostalCode"/>

As you can see, the complexproperty is defined within the Person mapping. That caught me off-guard for a while.

EFContrib support

I have not checked in the source yet, but I will shortly at
As you know, my contribution project to Entity Framework aims to help you use Entity Framework without all the generated code. You can just create your own domain model and add one attribute. The system will actually change the code to facilitate the EDM during compilation. Leaving you with a clean model.

It was actually quite difficult to implement this behind the scenes. To support normal entitytypes, I have to implement the three IPoco interfaces. But complex types are radically different. In the end, I had to alter the code I put into the setters of your properties.
I also had to somehow get hold of a list of properties in your type that are complexTypes (in this case Address). When the system injects your entitytype with a changetracker, it should notify all complex types. I could have done that with reflection, but we all know that's really slow. So I actually generate a method in your entity: 'UpdateComplexTypes(tracker)' and insert that with the correct IL to set the tracker in all the complextype-properties. So the solution is as fast as it can get, completely on par with handwritten c#. I may have to write another post on how I did it.

Our domain objects look like this:

  0 [Poco("ComplexTypesTestEntities")]
  1  public class Person
  2 {
  3   public int PersonID { get; set; }
  4   public string FirstName { get; set; }
  5   public string LastName { get; set; }
  6   public Address Address { get; set; }
  7 }
  9 [Poco("ComplexTypesTestEntities")]
  10  public class Address
  11 {
  12   public string City { get; set; }
  13   public string Street { get; set; }
  14   public string PostalCode { get; set; }
  15 }

Now, this code will work great:

  0    using (ComplexTypesTestEntities context = new ComplexTypesTestEntities())
  1    {
  2     // clear out database
  3     foreach (Person old in context.Person)
  4     {
  5      context.DeleteObject(old);
  6     }
  7     context.SaveChanges();
  9     Person p = new Person { FirstName = "Ruurd", LastName = "Boeke" };
  11     // this will set the changetracker
  12     context.AddToPerson(p);
  14     Address a = new Address { City = "Rotterdam", Street = "My Street", PostalCode = "1111 VA" };
  15     p.Address = a;
  17     IGetChangeTracker ctA = PostSharp.Post.Cast<Address, IGetChangeTracker>(a);
  18     Debug.Assert(ctA.GetChangeTracker() != null);
  20     Address b = new Address { City = "Seattle", Street = "redmond street", PostalCode = "2222 BB" };
  21     p.Address = b;
  22     Debug.Assert(ctA.GetChangeTracker() == null);
  24     IGetChangeTracker ctB = PostSharp.Post.Cast<Address, IGetChangeTracker>(b);
  25     Debug.Assert(ctB.GetChangeTracker() != null);
  27     context.SaveChanges();
  28    }

You can see me casting the object to the interface I implemented on lines 17 and 24.

Friday, 14 March 2008 17:36:55 (Romance Standard Time, UTC+01:00)  #    Comments [7]  |  Trackback
 Thursday, 13 March 2008

I have not taken the time to actually play with SL yet. But I have been watching the mix sessions and are very excited about what I see. However, from what I can gather, there are a few things missing. It seems important to get this news out soon, so Microsoft can start getting some customer feedback.

For starters, there is no combobox, but I must say that this really isn't a big problem. It might even be included in the final bits, or somebody will write one for sure. No biggy.

However, Karen's video highlights some shortcomings of styling: they are write once, no application theme style like we are used to and you can not use 'based on'. That is going to be awful to say the least!

Josh Twist has an excellent post up here, where he notices the missing elementname and relativesource bindings. He doesn't use the relativesource bindings much, but I can tell you, I've had to use them to enable some great scenario's. Not having them will limit me greatly (more then missing the elementname binding).

Finally, Rob Eisenberg triggered me to write this post, mainly to point to his post here. It's a great writeup of what he is missing. It appears there are not triggers around anymore. I had already noticed that SL is coming up with a new scheme for control template authors to define the 'states' and 'elements' that need to be implemented by a template author. However great that may be, they appear to have substituted this for the trigger functionality. I can tell you, that is just terrible. Triggers are a very important part of a wpf application, and like Rob, I would implore Microsoft to reconsider this.
He also notes there is no concept of the ambient datacontext anymore. wow.. that hurts. No longer parameter-less ctors for UIElement and Frameworkelement (so, you can only inherit from Control easily) and to me one of the most important features missing: no Commands!! That means we are in a world of pain.

I must say, this has diminished my expectations of Silverlight a little bit. I really hope some of these issues are fixed before going live, because they have proven so useful in WPF.

Thursday, 13 March 2008 10:07:17 (Romance Standard Time, UTC+01:00)  #    Comments [3]  |  Trackback
 Tuesday, 11 March 2008

The last couple of months have been great, working on stuff that I wanted to learn more about. Now it is time to start looking for new jobs again.

I'm a freelance software engineer based in Holland (Rotterdam). If you or your company is looking for help, you can hire me for a few days/weeks/months.
Since you're reading this blog, I'm sure you know that I love WPF, WF, WCF and EF alike, so I'm a pretty rounded in the new 3.0 technologies. Apart from jobs that work with those technologies, I'm also interested in jobs where I can coach a team of developers to work agile or where I can help design your next great architecture ;-)

So, if you need a hand, email me at: work at sitechno dot com.

Tuesday, 11 March 2008 18:02:57 (Romance Standard Time, UTC+01:00)  #    Comments [11]  |  Trackback