Archive for April, 2010

SimpleDB: pulling the plug on the deprecated Query API

Tagged as LightSpeed, SimpleDB Management Tools

When Amazon introduced the SimpleDB Select API and deprecated the earlier Query API, we switched LightSpeed over to generate queries using the Select API, but left in a compatibility option to force LightSpeed to generate Query API calls instead. This was a transitional option so that users had an “escape hatch” in case there were any bugs in the Select implementation.

The Select-based engine has now been in production for something over 6 months, so we believe that it is no longer necessary to provide the option to force LightSpeed to revert to the Query API. And maintaining a Query-based engine alongside the Select-based engine is now preventing us from implementing new features such as consistent reads.

Therefore, beginning with the 29 April 2010 nightly build, LightSpeed will always generate Select calls; the “force back to Query” option will be ignored. This shouldn’t cause any compatibility issues because it’s an internal change to the way LightSpeed invokes SimpleDB, not to the way you form your LightSpeed queries. However, if you are still using the “force back to Query” option and you do notice any differences after we turn it off, please let us know in the forums.

In addition, nightly builds of SimpleDB Management Tools will no longer support the Query syntax. If you’re writing queries in SimpleDB Management Tools, you will need to use the Select syntax. We’re pretty confident that most people have already switched over, but if you’re a deprecated API diehard, consider yourself warned!

Add your comments
Posted by Ivan Towlson on 27 April 2010

Class table inheritance in LightSpeed

Tagged as LightSpeed

As we’ve discussed before, one of the big impedance mismatches between the object and relational worlds is over inheritance. Inheritance is a tremendously useful concept in object-oriented programming, but relational databases don’t have that concept at all, and need to have inheritance relationships represented in a different way. There are three common patterns for representing inheritance hierarchies, which we refer to as concrete table inheritance, single table inheritance and class table inheritance.

In the past, LightSpeed has supported only concrete and single table inheritance. We know a number of customers have been keen to see class table inheritance added to the list, and we’re pleased to announce that current nightly builds of LightSpeed include support for class table inheritance.

What is class table inheritance?

Class table inheritance represents each class in a hierarchy with a table. Unlike concrete table inheritance, however, each table includes columns only for the properties introduced at that level of the hierarchy (plus the mandatory Id column which allows rows in the different tables to be identified as referring to the same entity).

The benefit of class table inheritance is that it reduces duplication of column definitions: for example, a Name column appears only in the Person table, rather than having to appear in each of the Person, Employee and Manager tables. The disadvantage of class table inheritance is that it requires a join across all the tables in the hierarchy: to load a Manager requires you to access each of the Person, Employee and Manager tables and to combine the results.

How can I use class table inheritance in LightSpeed?

First, you need to tell LightSpeed that you want to map the inheritance hierarchy to the database using class table inheritance instead of single or concrete table inheritance.

• To specify class table inheritance in the designer, select the inheritance arrow and set the Inheritance Type to ClassTableInheritance. You’ll need to do this at each level of the hierarchy.
• To specify class table inheritance in code, apply the new InheritanceMappingAttribute to the root class of the hierarchy, specifying InheritanceMappingKind.ClassTableInheritance.

Second, you need to specify a discriminator. This allows LightSpeed to know what kind of entity each row represents. The table for the root entity type must contain the discriminator column. Discriminators work in exactly the same way as in single table inheritance:

• To specify a discriminator in the designer, select the inheritance arrow and set the Discriminator Name, Discriminator Type and Discriminator Value.
• To specify a discriminator in code, apply the DiscriminatorAttribute to the derived class.

By the way, the designer supports creating tables for class table inheritance mappings, so rather than building the tables by hand, you can create your inheritance hierarchy in the designer, set up the inheritance relations to be class table inheritance, and use the Update Database command to create the tables with all the right columns.

When should I use class table inheritance in LightSpeed?

Class table inheritance is a good fit when you need polymorphism, but have a lot of columns that make sense only for child entities.

If you don’t need polymorphism, concrete table inheritance gives you better performance because it avoids the need to join over every table in the hierarchy.

If you need polymorphism but your derived classes don’t introduce extra state (only behaviour), or only a little extra state, single table inheritance provides polymorphism and again avoids the performance penalty of the join.

In particular, the join cost may be prohibitive if you have a very deep or wide hierarchy: every table in the hierarchy participates in the join, which can be costly if there are a large number of tables.

Where can I get it?

Class table inheritance is included in current nightly builds of LightSpeed. You can get download LightSpeed Express edition for free, or if you’re a retail customer you can get the latest build from the store. Class table inheritance is in beta right now so if you run into any problems please let us know on the forums. Check it out!

Add your comments
Posted by Ivan Towlson on 27 April 2010

Introducing Visual Tools for SharePoint

Tagged as Beta, Products, SharePoint

With Office 2010 and SharePoint 2010 being released today to MSDN subscribers it’s time to take the wraps off our latest creation: Visual Tools for SharePoint. Stunning name, very Microsoft inspired! ;-)

Get Visual Tools for Sharepoint FREE

The first 50 people to create accounts with Mindscape (click here to register) and then email their username and email address to jd@mindscape.co.nz will get a free license to Visual Tools for SharePoint. I’ll update this post when the give aways are complete, but be quick! UPDATE: All the free copies have been taken sorry!

What would you say…. you do?

Visual Tools for SharePoint is our first SharePoint related product and one of the exciting new features in SharePoint 2010 is “LINQ to SharePoint”. As many of you will know, our LightSpeed product has a fantastic LINQ provider and design surface for databases, so we are interested in all things LINQ. Microsoft have not made a visual design surface in Visual Studio for modeling things in SharePoint that you wish to query – you need to use an arcane command line tool. We love our Visual Studio integration and decided we could do better!

Here’s a screenshot (click to see it larger):

So you can connect to SharePoint from the VS 2010 Server Explorer, drag and drop your lists and have us create LINQ to SharePoint contexts and classes for you. No more mucking around with command lines and XML configuration files! This helps developers save time, makes generating your objects to query much easier and saves you having to leave Visual Studio 2010. Plus you can quickly update your models from the SharePoint site so as to see what’s new or changed.

What do you think?

With any new product we need end user feedback – that’s why we’re giving away copies to the first 50 users. You’ll get immediate access to the beta and a free copy of the toolkit when the retail version ships. (You’ll need Visual Studio 2010 Professional or above, and SharePoint 2010, to use the product.)

We want to evolve all of our products based on the feedback we receive and make all the changes available to users through our much loved nightly build process. Please let us know what you think in the comments on this post or in our forums :-)

So what are you waiting for? Sign up and email us your username and email address now!

Add your comments
Posted by John-Daniel Trask on 22 April 2010

SimpleDB Management Tools for Visual Studio 2010 released

Tagged as SimpleDB Management Tools

We’re pleased to announce that SimpleDB Management Tools is now available for Visual Studio 2010. VS2010 versions of our other products will follow over the coming days and weeks.

SimpleDB Management tools makes it easy to work with your Amazon SimpleDB domains, attributes and data right from within Visual Studio. You can quickly connect to SimpleDB instances from the Visual Studio Server Explorer, query data, and add edit and delete domains and attributes. With the new version you can do all this from within VS2010 as well.

Please note that the 2008 and 2010 releases are separate downloads — if you want to use SimpleDB Managemement Tools in both environments, you’ll need to install both components.

The 2010 release is free to existing users, and available now for download from the store. There’s also a free trial edition (limited to viewing or editing 20 records per domain). If you’re using VS2010 and Amazon SimpleDB, take it for a spin today!

Add your comments
Posted by Ivan Towlson on 15 April 2010

WPF Diagramming: Connection validation and an API change

Tagged as Products, WPF, WPF Diagramming

One important feature that some diagrams need is connection validation. That is, the ability to control which diagram nodes are allowed to be connected together. For example, you might want node A to be connectable only to node B. Or you may want to prevent start nodes being connected to end nodes. Many different diagrams will require their own unique connection validation which is why WPF Diagramming provides a way for you to customize this logic. The two interfaces that you need to consider when providing your own logic is the IDiagramConnectionBuilder and the IDiagramConnectionRelocator. The connection builder contains a method for building a connection and adding it to the diagram, and the relocator has a method for performing the connection relocation. Originally, custom connection validation would be taken place in your own implementations of these methods. A disadvantage of doing it this way is that the user interface is oblivious to this validation. Because of this, the user would only know if a connection can not be made between particular nodes after they let go of the mouse button and find that no connection is created. However, a recent modification to these two interfaces solves this issue. In this blog post we look at this modification that has been made, as well as how to provide your own connection validation logic to your applications.

Connection builder and connection relocator API change.

Both the IDiagramConnectionBuilder and the IDiagramConnectionRelocator now has an additional method that returns whether or not they are allowed to perform their respective actions. The new connection builder method is called CanCreateConnection which has the following parameters:

• IDiagramModel. This is simply the diagram that the new connection is going to be added to.
• IDiagramConnectionPoint. This is the connection point where the new connection is going to originate. Using the Connectable property on this connection point gives us access to the diagram node that the connection will be attached to.
• ConnectionDropTarget. This is a new type of object that contains information about where the user is dragging the end of the connection to.

This method is also called in the situation where the user has just pressed the mouse button on a connection point thumb in preperation to create a connection. This allows you to provide connection validation logic that prevents certain types of connections being made on certain types of nodes. One thing to be aware of is that the ConnectionDropTarget parameter will be null to represent this situation.

The new connection relocator method is called CanRelocateConnection and contains all the parameters as previously mentioned as well as the IDiagramConnection that is being relocated. One thing to note is that the IDiagramConnectionPoint parameter is the connection point that the connection is still attached to, and the ConnectionDropTarget holds information about the end of the connection that the user is dragging.

Custom connection validation logic

Now that we know the basics, lets implement our own connection validation logic for a flow diagram to follow. Our logic will simply prevent any StartNode elements from being directly connected to an EndNode element. We want both our IDiagramConnectionBuilder and IDiagramConnectionRelocator implementations to share the same connection validation logic, so we can write it in a static method as follows:

public static class ConnectionValidationLogic
{
  public static bool ValidateConnection(IDiagramConnectionPoint connectionPoint, ConnectionDropTarget dropTarget)
  {
    bool canCreateConnection = true;
    if (dropTarget != null)
    {
      IDiagramConnectable source = connectionPoint.Connectable;
      IDiagramConnectable destination = dropTarget.Connectable;
      if (source is StartNode && destination is EndNode)
      {
        canCreateConnection = false;
      }
    }
    return canCreateConnection;
  }
}

For our validation logic we will only be interested in the source and destination of the connection. So the only parameters we need for this method is the IDiagramConnectionPoint and the ConnectionDropTarget object. As previously mentioned, the drop target object will be null in a special situation so we include a null check around the rest of our logic. We can aquire the source item of the connection by using the Connectable property on the connection point, and the destination item can be obtained with dropTarget.Connectable. Then all our logic needs to do is return false if the source is a StartNode and the destination is an EndNode. Later when we give this logic to the diagram, we will get the following results:

Here on the left we can see the user is creating a connection from the start node and hovering the mouse over the process node. Our validation logic allows this and so the connection points on the process node are shown. However, when hovering the mouse over the end node, the validation logic notices that this is illegal and so the connection points stay hidden.

Now that we have set up the validation logic, we need to make a connection builder and connection relocator implementation that uses it. We can do this easily by extending the FlowDiagramConnectionBuilder and DefaultDiagramConnectionRelocator classes and overiding the appropriate methods. In the implementation of these methods, we simply make a call to our static validation logic method, and return the result as follows:

public class ValidatingConnectionBuilder : FlowDiagramConnectionBuilder
{
  public override bool CanCreateConnection(IDiagramModel diagram
                                                          IDiagramConnectionPoint fromConnectionPoint,
                                                          ConnectionDropTarget dropTarget)
  {
    return ConnectionValidationLogic.ValidateConnection(fromConnectionPoint, dropTarget);
  }
}

Providing the diagram with the validation logic.

Now all thats left to do is give our custom logic to the diagram. This is easily done by setting the appropriate diagram properties to be instances of our connection builder and relocator classes.

FlowDiagramModel diagram = new FlowDiagramModel();
diagram.DefaultConnectionBuilder = new ValidatingConnectionBuilder();
diagram.ConnectionRelocator = new ValidatingConnectionRelocator();

And thats it!

There are many connection validation scenarios that can be handled in this way. You could prevent certain types of nodes being directly connected to themselves, only allow specific types of connections to be made between certain node types, or even prevent particular diagram node instances from being connected together. If you download the latest nightly build you will find a new project in the flow diagram samples solution called ConnectionValidationSample. The sample prevent StartNodes being connected to EndNodes, DecisionNodes can only be accessed by a StartNode, and data-ProcessNodes can not connect to themselves. Use this to see how it all works and give you ideas to implement your own validation logic.

Try this out if you are in need of custom connection validation. If you are having trouble getting it to work or can’t seem to get the logic right for a certain scenario, then let us know in our forum, or put a comment on this blog post.

Add your comments
Posted by Jason on 13 April 2010