Tonight I have been looking into pluralisation (pluralization) with regard to Linq to SQL and how it handles different table names. As some of you might be aware, there are two ways of creating the mapping between database and objects, one is using the Linq to SQL designer built into Orcas, the other being a command line tool called SQLMetal. The Linq to SQL designer automatically pluralises the table names where as with SQLMetal you have to add the command line argument ‘/pluralize’.
With most nouns, it simple involves adding a ‘s’ onto the end of the word. So Order becomes Orders. Then there are some require ‘es’ such as gas become gases. The other types are irregular plurals, which are a bit more complicated, for example person becomes people and sheep stays as sheep.
In the DataContext Orders is a property on the DataContext which calls this.GetTable
To start with, I created the DataContext using the designer. The designer always displays the name as a singular as when designing you are only working with a single instance of the type. In the .designer.cs class, the generated C# code is stored and this is where you can see the various properties which have been created and see how the table has been pluralised.
When dragging on simple table names such as Categories and Country it can understand the relationship between plural and single, for example Category and Categories and create the objects accordingly. However, when it got onto more complicated types such as Gas or People, it wouldn’t pluralise correctly and create Peoples while Gas would become Ga. SQLMetal would do the same.
One interesting point is that if you create your DataContext using SQLMetal and you have two tables, Category and Categories in the same database, then it will create Categories and Categories2, where as the designer will create Categories and Category1s. Going to be interesting to see how the product team handles this situation.
It is a shame that the two do not produce the same result, this might be due to the way the designer creates the code as the tables are added onto the design surface whereas sqlmetal does a batch process; hopefully in the final release they will always produce the same result.
Also at the moment there is no way to refresh the diagram if the underlying table changes within Orcas. At the moment you have to delete the object and drag it on again. Not great if you have created custom properties.
All this said; it is only beta 1.