Sunday, September 21, 2008

Forcing Gratuitious Pluralization of EF EntitySet Names Was a Very Bad Decision

Following is the full text of my How to Disable Unwanted EntitySet Pluralization in v1? thread of 9/20/2008 in the ADO.NET Entity Framework and LINQ to Entities (Pre-release) forum:

Jarek Kowalski says in EF Newbie Question on Pluralization: "Pluralization of entity set names and singularization of entity type names is not supported in EFv1 tools, but we're considering adding them in future releases."

As of EF v1's RTM I find the above to be incorrect. Manually singularizing EntityObject names pluralizes EntitySet names by renaming them to the singularized version and adding a "Set" suffix (e.g., renaming Customers to Customer generates a CustomerSet EntitySet name.) This requires manually changing the name of each EntitySet in the entity’s Properties sheet back to its original plural form.

Pluralization occurs with the Tools | Options | Database Tools | OR Designer | Pluralization property set to false. The Pluralization option description reads "Controls whether pluralization is applied to names when creating objects. Pluralization is only enabled for English." The description infers that only Pluralization is affected, which is what the EDM Designer is doing, not Singularization; LINQ to SQL's OR Designer does Singularization.

I'm curious why the EF tools devs foisted an ugly pluralization naming convention on unsuspecting users and then didn't choose the obvious approach to turning it off. Was it because the term "OR Designer" would denigrate the "EDM Designer?"

Further, beta testers weren't given the opportunity to complain about this unwanted and unhelpful operation or notified about the change in Jeff Derstadt’s Entity Framework RTM Breaking Changes post to the ADO.NET Team Blog of August 12, 2008.

How do I turn this so-called "feature" off?

Not only was the pluralization gratuitous, it was inserted by a stealth process into EF’s SP1 RTM. I discovered the operation when updating EF Beta 2 code for my forthcoming Professional ADO.NET 3.5: LINQ and Entity Framework book for WROX.

Although the Northwind database is the example data source in much of EF’s documentation, the only use of sample EntitySets having names suffixed with “Set” that I can find is Entity Containers (EDM).

If I had detected it in time, I probably would have signed the ADO.NET Entity Framework Vote of No Confidence manifesto.

I’d like to know how many EF beta testers requested this bogus “feature.” It’s arbitrary and capricious design decisions like this that led to the manifesto.

Note: Fortunately, Huageti Systems’ Huagati DBML and EDMX Tools has an EF (and LINQ to SQL) add-in that has a “renaming function that goes through all entity sets, entity types (classes), properties, and navigation properties in a EDMX file (EF designer) and renames them according to a user-selectable set of rules.”

Update 9/21/2008: The Singularizing EntityType and Pluralizing EntitySet Names with the Huagati DBML/EDMX Tools post of 9/21/2008 demonstrates the Huagati DBML and EDMX Tools’ capabilities.

More Fuel on the Fire: Mike Pizzo’s Reply to an Earlier Question

EF Data Architect Mike Pizzo wrote the following on 10/26/2007 in reply to JPAK’s Linq to entities and LIKE question in the same forum

Pluralization (and "Singularization") is one of the features we looked hard at for the designer (and underlying API) but had to cut for version 1.  The problem is not with the code (we actually have a couple of routines that are pretty advanced that we could borrow from) but with testing all of the different variations.

There is also the issue that the pluralization rules would be [E]nglish-language based (so we'd need a way to disable them for other languages), but we still believe even an [E]nglish-only version would be useful.

The only saving grace is that the designer does make it relatively easy to rename entities, but this is still one of my top 5 features that I wish we could have gotten in for version 1 (but leaves us something to do for V2... :-)

The above leads to questions regarding how and why the “feature” turned up in the final product.

Update 9/20/2008 11:45 AM PDT: According to Microsoft’s Noam Ben-Ami in a reply to my question:

We have heard other complaints about this behavior and it will be turned off in the next release, to which we are working on adding [E]nglish language pluralization/singularization. There is no setting at this time that controls this behavior.


Frans Bouma said...

It keeps surprising me how incapable Microsoft's architects are in some situations, like this one.

I mean, in llblgen pro I solved this with a simple plugin binding: the designer can raise events and you can bind a plugin to these events. Two of these events are: pluralization of a name and singularization of a name. Added to that I have a pattern system for names so people can specify, with macros like $S and $P, $StartEntityName etc., how the names should be constructed, for example the name mapped onto a relationship of type 1:n, or m:1. We ship 1 plugin for pluralization/singlularization which is based on the castle pluralization class and it's thus open source. It's for english, but anyone can change the code and make it compatible for his/her own language, and due to the patterns (which are simply project properties) one can define the name formats how they like them to be, including pluralization/singularization.

Now, if I can come up with such a system and build it in a week or so, why can't they cook up such a system with their multi-million dollar team of highly qualified architects?

I have the feeling the EF team is talking too much, having a lot of meetings about small features instead of hammering out code.

Oh well... :)

--rj said...


Huagati System's renaming feature was basically an afterthought that Kristofer Andersson added to the utility's basic feature: updating LINQ to SQL mapping for schema changes.