LightSpeed

• Fixed invalid UPDATE statements when a class table inheritance hierarchy contained a level with no persistent fields
• Added support for further Visual Basic Group By overloads
• Fix for KeyNotFoundException when sorting on the property of an eager-loaded child entity when the association is nullable
• User- and provider-defined types are now displayed in alphabetical order in the designer Data Type drop-down
• Added validation in the designer to detect if an association was redeclared in a derived class
• Fix to allow the designer to work with integrated authentication on Oracle
• The results of Count are now aligned with the results of Find and Count Distinct in paging scenarios

These fixes and enhancements are available in current nightly builds — you can get the free Express edition from the downloads page or the retail edition from the store.

LightSpeed

• Fix for designer DTO compilation error if entities were declared internal
• Fix for ordering a query on a property of an associated entity when the association is declared in a derived class and the mapping mode is class table inheritance
• Fix for LINQ projections on SimpleDB
• Fix for generation SQL Compact blob columns from designer
• Fix for inequality comparisons and unique validations on SimpleDB
• Added a feature to the VS2010 designer to warn if the project targets the .NET Client Profile
• Fixed an issue where an empty linked model caused a compiler error
• Fixed “arrows to nowhere” when using external class references in VS2010 designer
• Fixed spurious table creation with auto through entities with ambiguously singular/plural names

WPF Elements

• Added an option to TimePicker to auto-refresh the list of suggested times

All these fixes and features are included in the currently downloadable nightly builds — free editions from the downloads page, retail editions from the store.

LightSpeed

• Added support for ToString() and Convert.ToString() in LINQ expressions
• Fix for aliasing issue in joins
• Removed some validation options from the designer for data types where they didn’t make sense (for example, length validations on boolean properties)
• Fixed an issue with using SqlXxx data types that was causing problems for SQL Server 2008 spatial queries
• Support composite (&& and ||) expressions in Where Any and All clauses. (Limited to a single && or || on VistaDB due a parameter handling issue.)
• Added support for projections in join criteria
• Added support for scoped subqueries in a LINQ Where clause
• Fixed an issue with scalar queries in class table inheritance, which also affected unique validations
• Support Query.Identifier in “update by query”

WPF Elements

• Added a 24-hour clock display option, Maximum and Minimum constraints, TimeSuggestionInterval option and input masking to the TimePicker control
• Fixed an issue with separator display in numeric text boxes

Silverlight Elements

• Added an ObservableDictionary class

These fixes and enhancements are in the current nightly builds — grab the free editions from the downloads page or the retail editions from the store.

Silverlight Elements

• The MulticolumnTreeView control now supports alternating row colours.
• We’ve added the new MultiCalendar control to our custom styles.

LightSpeed

• We’ve fixed a limitation on eager loading on inheritance hierarchies. Previously we would only eager load associations declared at or above the level of the queried type. We now also eager load associations declared on derived types.
• Also on the inheritance theme, we’ve fixed a bug which resulted in incorrect SQL when a query involved an associated object of a class table inheritance derived type, but the property in the query was declared on a base type rather than the associated type.
• We’ve fixed an issue which could cause entity settings not to be displayed in the VS2008 designer.
• We’ve added a way to decouple property and field names. This can be handy in inheritance scenarios, where a column can mean different things depending on which derived class you’re in.

All of these fixes and enhancements are available in the current nightly builds, available from the store or (for free and trial editions) from the downloads page.

Silverlight Elements

We’ve added a new MultiCalendar control to Silverlight Elements, which allows you to display multiple months and select multiple dates, either as a range or as multiple dates or ranges.

LightSpeed

We’ve made several improvements around joins this week. You can now use multiple criteria in joins, and in LINQ you can conveniently express this by using an anonymous type as the join argument. We’ve also added some support for querying on through associations.

We’ve also provided a way to resize entities vertically in the designer, for those cases where you have an entity with very few properties but lots of associations. Vertical resizing isn’t turned on by default because it can impair usability, but if you have entities like this then you can read about the secret squirrel trick here.

Finally, we’ve released a number of minor fixes and tweaks:

• Auto through entities weren’t being given the right identity type when creating the database tables in the designer.
• We now allow migrations projects to be in solution folders rather than requiring them to be at the root.
• We’ve fixed an issue where the designer custom template path wasn’t being shown for editing if the .lsmodel file was in a subfolder. We’ve also fixed an issue with missing projects in a solution.
• Fixed support for the Visual Basic LINQ Group … By syntax.
• Some fixes for .Equals support in LINQ expressions.
• We have added partial support for discriminated derived types in assemblies other than the one which defines the base type. This only works in limited situations though — if you’ve got a more complex assembly arrangement then let us know.
• Fix for the designer not ignoring transient properties when creating a new database table.

As always, you can get the latest nightly builds from the My Account page in the store.

For example, suppose we have employees and projects: an employee can work on many projects, and a project can be worked on by many employees. So we would have a through association between the Employee and Project entities, and a through entity type to support it, typically called something like EmployeeProject. Each EmployeeProject has references to one Employee and one Project. Plus, because an EmployeeProject is an entity, it has an ID.

So far, so good. But a common idiom at the database level is to say, “Well, hang on. An EmployeeProject is uniquely identified by its EmployeeId and ProjectId. Why are we wasting precious bytes on an ID? Why don’t we make EmployeeId and ProjectId a composite primary key?”

Well, the answer to that is, “Because it will make your life harder.” LightSpeed 3 supports composite keys, but they’re not as easy to work with as surrogate keys. And until recently LightSpeed hasn’t been able to use an ID as the key for an association, so it’s required hand-coded workarounds to realise the association. So if you have the option, it’s just easier to use the separate ID column.

But if the through table already exists and uses the composite primary key, then this option may not be available to you. In which case, how do you work with the composite key and the associations that use parts of the composite as their foreign keys?

The answer comes in two parts — the first part is standard LightSpeed composite key handling, and the second is a new mapping feature in LightSpeed 3.1.

1. Defining the Through Entity With a Composite Key

Our through entity is going to have a composite key consisting of the EmployeeId and ProjectId. We’ve previously discussed how to define such a composite key in code. You can also create it in the designer by just dragging the table onto the design surface.

You’ll also need to override the GeneratedId() method to tell LightSpeed how to assign composite key values. This is discussed in the linked article.

You can now set up the one-to-many associations from Employee and Project to the through entity, and the through association between the Employee and Project classes. Here’s how it looks in the designer at this stage.

2. Backing the Associations onto the Composite Key

At this point, we still have a problem with our one-to-many associations. When LightSpeed sees an association called Employee, it also expects to see an EmployeeId property to hold the foreign key value. It expect this so much that the designer automatically creates this property for you. Trouble is, we don’t want that property, because in our case the foreign key value is the EmployeeId part of the composite key.

To tell LightSpeed to back the Employee association onto some other property rather than the automatic EmployeeId property, we use the Key Property Reference setting. Key Property Reference tells LightSpeed to use an existing property as the foreign key store, rather than the automatic property. The important thing for our composite key scenario is that Key Property Reference supports subproperties. So if we put “Id.EmployeeId” as the Key Property Reference, LightSpeed will use the EmployeeId property of the composite Id as the foreign key. Which is exactly what we need.

(To do this in code, apply the ForeignKeyFieldAttribute to the EntityHolder field. The same path applies in both cases.)

We need to do a similar mapping on the EmployeeProject.Project association, setting the Key Property Reference in this case to Id.ProjectId.

And we’re done! Our through entity now supports many-to-many associations between Employees and Projects without the need for an additional surrogate key.

To reiterate, you’ll usually use this technique only with legacy databases that you can’t change. If you have the choice, it’s much easier to have a separate Id column for all of your entities, including through entities. But if you need to work with an existing database that uses foreign keys as primary keys, Key Property Reference and the ForeignKeyField attribute are the way to do it!

Want to know more? Download the free LightSpeed Express edition and try it out!

WPF Elements

We’ve been continuing to enhance WPF Elements with some of the controls from our Silverlight Elements suite. Since the last bulletin we’ve added:

• SplitButton
• DualSlider
• OutlookBar

These controls are available in the current nightly build — check them out!

We’ve also fixed a bug where the IntegerTextBox.ValueChanged event was getting declared incorrectly.

LightSpeed

• The DateTime.Date property is now supported in LINQ queries on SQL Server 2008. (It’s been supported on Oracle and PostgreSQL since 2.2.)
• We’ve made some further tweaks in support of .NET Remoting.
• We’ve made a number of bug fixes around class table inheritance, including some fixes for incorrect joins and aliasing, and an error where the schema wasn’t being respected on derived classes.

WPF Elements

We’ve started porting some of the cool controls from Silverlight Elements to WPF, and the following are done and included in the current nightly build of WPF Elements:

• DualProgressBar
• TimePicker
• TimeSpanPicker

Other controls will be arriving in future nightlies — we expect to make a proper announcement next week.

LightSpeed

• We’ve added some checking to the designer to provide a more meaningful warning if you create an association to a concrete table inheritance base class.
• Fixed a problem with validation when using .NET remoting.
• Fixed a designer bug which prevented you from using the tree view to add CLR attributes.
• We’ve fixed a problem in optimistic concurrency checking where version information was being updated on a failed save. This fixes a related issue which could result in concurrency checking being fooled by repeated save attempts.
• Updated SQLite provider to version 1.0.66.

Silverlight Elements

• The RichTextEditor now supports changing the background colour.

WPF Property Grid

• Fixed an issue with dangling event handlers which could cause memory leaks or errors in collection scenarios.

LightSpeed

• Designer support for nullable stored procedure arguments
• Fix for a LINQ issue using logical expressions involving nullable properties from Visual Basic

In other news, Jason has been forging ahead on WPF Diagramming 2.0, and it’s shaping up to be a very nice release with lots of cool new features. Thanks to everyone who provided feedback and suggestions!

For example, in an order fulfilment model you might identify three major areas: orders, logistics and customers. Each of these areas has a potentially complex internal model, but has relatively few links to the other areas. They’re not completely isolated, of course: a customer has orders, an order has shipments. But they can be developed independently: you can refine the way warehousing is modelled without having to muck around with the way orders or customers are modelled; and conversely things in the orders or customers sub-domains may care about shipments, but probably don’t care about anything deeper in the logistics domain.

In LightSpeed 3.1, you can represent a semi-partitioned domain like this using linked model files.

The pattern of internal cohesion with relatively few external links is characteristic of a good sub-domain, and it’s the key to using linked models. Linked models need some external references — otherwise there’s be no point linking them! — but you want to minimise these, so that each linked model is as standalone as possible. Otherwise you end up having to jump between models to make changes, which cancels out the simplicity benefits of splitting the big model in the first place. Thus, in this example, we’d create three linked model files: Orders.lsmodel, Logistics.lsmodel and Customers.lsmodel.

With linked model files, we can represent each sub-domain in its own file, with entities that are defined in other files but needed for associations represented as entity links. Here’s how it looks:

Notice how PurchaseOrder in the Orders sub-model is able to link to Customer in the Customers sub-model and Shipment in the Logistics sub-model via entity links to the Customer and Shipment entities:

How do I link model files?

A LightSpeed designer model has a Name property, which you can see and edit by clicking on the model background and going to the Properties window. Two models with the same Name are linked. It’s that easy.

Really? It’s that easy?

Well, it’s almost that easy. There are a couple of extra rules. First, the Target Namespace settings of the models must also be the same. Most people leave the Target Namespace as the project namespace, so you don’t normally need to do anything here. Second, all but one of the linked files must have Is Linked Child set to True. It doesn’t really matter which one is the “parent” — it’s just that there’s some code that we have to generate once and once only, so we have to pick a file to host that once-only code.

But apart from those two wrinkles, it’s that easy.

Couldn’t you make it any easier?

Sure. If you’ve got a model which is starting to get a bit on the bulky side, you can right-click a one-to-many association that divides the model in two and choose Refactor > Split Model at Association. (If there’s no one single association which splits the model in two, you can select multiple one-to-many associations which between them split the model in two.) Enter the name of the new file, choose which half of the model you want to move into the new file, and Bob’s your uncle. The new file will automatically be given the same model name and target namespace as the “parent” file, and will be set as a linked child.

Also, if you use the Paste as Link command to create an entity link, it will check that the two files are linked, and offer to link them if they’re not.

So I have my linked files. How do I make a model that spans them?

As discussed above, linked models work best when there are relatively few associations that span files. If you have too many associations that span files, then you’ve not got good isolation between your sub-domains, and you’re likely to have to alter multiple files to make any change. But of course you need to be able to create some associations that span files. Here’s how.

First, identify the two entities you want to associate. Let’s say you want to model that an Order has a collection of Shipments. Order is defined in Orders.lsmodel and Shipment in Logistics.lsmodel.

Second, copy each of those entities in turn, and use the new Paste as Link command to paste a link to that entity into the other file. For example, select the Shipment entity in Logistics.lsmodel, press Ctrl+C to copy it to the Clipboard, switch to Orders.lsmodel, right-click the background and choose Paste as Link. You’ll see an entity link appear in Orders.lsmodel — you can tell it apart from a normal entity because it has a link icon and says “Link to” in its descriptive text.

Now do the same operation in reverse, copying the Order entity from Orders.lsmodel and pasting it as a link into Logistics.lsmodel.

Third, create the association in both files. In each case, you create the association normally, by selecting OneToManyAssociation from the toolbox and dragging an arrow from Order to Shipment. But you need to do it twice: once in Orders.lsmodel and once in Shipment.lsmodel.

Save the files and you’ll now find that your Order class includes a Shipments property and your Shipment class includes an Order property! Of course you can rename the ends of the association and set properties as usual — just remember to do it in both places.

Man, that’s like fourteen clicks.

I warned you! Cross-file associations aren’t as convenient as intra-file associations. If you’re having to create a lot of them, maybe you should be splitting your model in a different place. Or maybe linked models aren’t a good fit for your problem domain.

Yeah, but fourteen clicks. I’m a busy guy. Minesweeper doesn’t play itself, you know.

A lot of models are evolutionary: that is, rather than creating three .lsmodel files on day one, you’ll start out with a single .lsmodel file, and break it up about the eighteenth time someone else asks you when you’ll be finished with it. When this happens, you can use the Refactor > Split Model at Association command to partition the model. This will create the necessary links and “duplicate” associations. Three clicks and a few keystrokes.

We’ll also be working to improve this experience in future nightly builds.

Anything else I need to watch out for when using cross-file associations?

It’s important to realise that entity links aren’t really links — they’re more like references, and they can get out of date. If you change, say, the identity type of the entity, you need to update the links to that entity to reflect that change. Similarly if you have a cross-file association and you change its properties, you need to change them in both places.

Fortunately, LightSpeed does give you a bit of help with this. You can right-click a linked model and choose the Check Links command to verify that links and associations are up-to-date. For some inconsistencies, LightSpeed can fix the problem automatically: we can’t yet do this for all inconsistencies, but again it’s something we plan to improve in the nightly builds.

Where can I get it?

Linked models are supported in all editions of LightSpeed 3.1, in both Visual Studio 2008 and Visual Studio 2010. If you’re a customer, LightSpeed 3.1 is in the store now. If you’re not… well, normally at this stage I’d exhort you to download the free Express edition and give it a try, but the free Express edition is limited to eight entity types, which hardly counts as large model territory. But what the heck. We think this is a pretty handy feature for dealing with large models, and we’d love to hear your feedback on how we can improve it. So go ahead: download it anyway.