Stupid Naming Consequences with LINQ
-
Here's another good reason not to use reserved names. I'm working on a LINQ project with a series of tables that manage user roles. As a result, I have table names like Systems, Roles and Users. My trouble started when I would add the objects to the Designer, hit Save and then suddenly Visual Studio would say things like System.Data.Linq.Mapping.DatabaseAttribute is not defined or System.Nullable is not defined In short, stopping me dead in my tracks. Now that I look back, I don't know why I didn't see the reason earlier. When using the Object Relational Designer, Visual Studio wants to be smart and changes any words that are plural to singular so they make more sense when dealing with data. That way, your code looks like
oUser = New User oUser.UserName = "John"instead ofoUser = New UsersThis is really nice because it does make the code a little more legible except in this situation: Plural (singular) Users (User) Roles (Role) UserRoles (UserRole) Systems (System) See the gotcha? Visual Studio translated the "Systems" table into a "System" object which immediately negated all of the main namespaces in the project. The renaming feature for the objects in LINQ-to-SQL is great - but be warned, when you start getting errors like this, take a look at your source tables. -
Here's another good reason not to use reserved names. I'm working on a LINQ project with a series of tables that manage user roles. As a result, I have table names like Systems, Roles and Users. My trouble started when I would add the objects to the Designer, hit Save and then suddenly Visual Studio would say things like System.Data.Linq.Mapping.DatabaseAttribute is not defined or System.Nullable is not defined In short, stopping me dead in my tracks. Now that I look back, I don't know why I didn't see the reason earlier. When using the Object Relational Designer, Visual Studio wants to be smart and changes any words that are plural to singular so they make more sense when dealing with data. That way, your code looks like
oUser = New User oUser.UserName = "John"instead ofoUser = New UsersThis is really nice because it does make the code a little more legible except in this situation: Plural (singular) Users (User) Roles (Role) UserRoles (UserRole) Systems (System) See the gotcha? Visual Studio translated the "Systems" table into a "System" object which immediately negated all of the main namespaces in the project. The renaming feature for the objects in LINQ-to-SQL is great - but be warned, when you start getting errors like this, take a look at your source tables.This reminds me of, "automagically", in the Buzzwords Hall of Shame, and makes me wish you didn't like the feature; because auto-complete is good, but auto-editorialize is nonsense and dangerous, as you just illustrated. Programming != Word Processing. X|
<Pretentious> Raid tha manyuhl. :E <Pretentious> Aw raid eh own mah meaxbile. :E
-
Here's another good reason not to use reserved names. I'm working on a LINQ project with a series of tables that manage user roles. As a result, I have table names like Systems, Roles and Users. My trouble started when I would add the objects to the Designer, hit Save and then suddenly Visual Studio would say things like System.Data.Linq.Mapping.DatabaseAttribute is not defined or System.Nullable is not defined In short, stopping me dead in my tracks. Now that I look back, I don't know why I didn't see the reason earlier. When using the Object Relational Designer, Visual Studio wants to be smart and changes any words that are plural to singular so they make more sense when dealing with data. That way, your code looks like
oUser = New User oUser.UserName = "John"instead ofoUser = New UsersThis is really nice because it does make the code a little more legible except in this situation: Plural (singular) Users (User) Roles (Role) UserRoles (UserRole) Systems (System) See the gotcha? Visual Studio translated the "Systems" table into a "System" object which immediately negated all of the main namespaces in the project. The renaming feature for the objects in LINQ-to-SQL is great - but be warned, when you start getting errors like this, take a look at your source tables.Had a similar problem few months ago. I had "Language" table in database basically storing all languages, that were used for multi-language stuff. Then when database schema was finished, I began working on data access layer and DataSet designer failed miserably on that "Language" table. I don't recall what the problem was exactly, but the "Language" name was a no-no. Cheers
-
Here's another good reason not to use reserved names. I'm working on a LINQ project with a series of tables that manage user roles. As a result, I have table names like Systems, Roles and Users. My trouble started when I would add the objects to the Designer, hit Save and then suddenly Visual Studio would say things like System.Data.Linq.Mapping.DatabaseAttribute is not defined or System.Nullable is not defined In short, stopping me dead in my tracks. Now that I look back, I don't know why I didn't see the reason earlier. When using the Object Relational Designer, Visual Studio wants to be smart and changes any words that are plural to singular so they make more sense when dealing with data. That way, your code looks like
oUser = New User oUser.UserName = "John"instead ofoUser = New UsersThis is really nice because it does make the code a little more legible except in this situation: Plural (singular) Users (User) Roles (Role) UserRoles (UserRole) Systems (System) See the gotcha? Visual Studio translated the "Systems" table into a "System" object which immediately negated all of the main namespaces in the project. The renaming feature for the objects in LINQ-to-SQL is great - but be warned, when you start getting errors like this, take a look at your source tables.I really do not think that the Object/Relational Designer should do any such renaming. I understand the rationale behind recommending that these names be singular, but it is not the place of the Object/Relational Designer to enforce this. This is the sort of thing that drives programmers away from the IDE "power tools" and I think this is a shame.
-
I really do not think that the Object/Relational Designer should do any such renaming. I understand the rationale behind recommending that these names be singular, but it is not the place of the Object/Relational Designer to enforce this. This is the sort of thing that drives programmers away from the IDE "power tools" and I think this is a shame.
I may be wrong but I think there is an option to turn this "pluralization" behaviour off.
-
I may be wrong but I think there is an option to turn this "pluralization" behaviour off.
I think it should be an option to turn the feature on.
<Pretentious> Raid tha manyuhl. :E <Pretentious> Aw raid eh own mah meaxbile. :E
-
Here's another good reason not to use reserved names. I'm working on a LINQ project with a series of tables that manage user roles. As a result, I have table names like Systems, Roles and Users. My trouble started when I would add the objects to the Designer, hit Save and then suddenly Visual Studio would say things like System.Data.Linq.Mapping.DatabaseAttribute is not defined or System.Nullable is not defined In short, stopping me dead in my tracks. Now that I look back, I don't know why I didn't see the reason earlier. When using the Object Relational Designer, Visual Studio wants to be smart and changes any words that are plural to singular so they make more sense when dealing with data. That way, your code looks like
oUser = New User oUser.UserName = "John"instead ofoUser = New UsersThis is really nice because it does make the code a little more legible except in this situation: Plural (singular) Users (User) Roles (Role) UserRoles (UserRole) Systems (System) See the gotcha? Visual Studio translated the "Systems" table into a "System" object which immediately negated all of the main namespaces in the project. The renaming feature for the objects in LINQ-to-SQL is great - but be warned, when you start getting errors like this, take a look at your source tables.I once had this bad experience too, and at that time we noticed that having database tables with Portuguese names would solve the problem (although we might have had problems with pluralization/singularization...)
Take a look at Soccerlight World Cup 2010 here in Code Project.
-
I really do not think that the Object/Relational Designer should do any such renaming. I understand the rationale behind recommending that these names be singular, but it is not the place of the Object/Relational Designer to enforce this. This is the sort of thing that drives programmers away from the IDE "power tools" and I think this is a shame.
_beauw_ wrote:
but it is not the place of the Object/Relational Designer to enforce this.
That's why you can disable it: Model IDE->Properties->Pluralize New Objects Please note that this is a pure religious issue: In my case, all my tables are singular names(Login, Person, Role, etc). So I would have had a table named "System" and without the pluralization on, I would have had to map them differently to avoid this collision. You can map the tables any way you like in EF4. Fact is, you'll always run the risk of name collisions with any code generation.
Before .NET 4.0, object Universe = NULL;