Ok, totally new, just tinkering for the first time with 3.0.

It seems that for case sensitive databases, there is a setting to add underscores between words when generating a database element name, but this setting is ignored for SQL Server (case insensitive)?

How can I get underscores between my words for SQL Server?

Also, I'm curious why was this limited to case-sensitive databases?

Thanks,

Phil

It's indeed only for case sensitive databases. We added this feature (the two settings actually) to make a difference for case sensitive databases which see names differentiating on case differences in table/field names as different names. By default the designer produces names like the ones in the model. On case sensitive databases this isn't in the casing used in almost all cases: DBAs use either all uppercase or all lowercase. When you use that, you also likely want underscores.

For SQL Server the name FooBar is the same as FOOBAR, hence we only use these settings for case sensitive databases.

You want underscores in the names in sqlserver as well, like Foo_Bar ?

Yes, absolutely. To quote myself from comments in my blog (http://psandler.wordpress.com/2009/12/10/database-standards-and-conventions/):

it may be thin, but underscores force the separation and easy reading of words within a name. In SQL Server (which is by far the database I use the most), names are not case sensitive, and casing is a much bigger factor if you use straight camel casing than if you use underscores. For example, “AssignmentTypeConfiguration” becoming “assignmenttypeconfiguration” vs. “assignment_type_configuration” becoming “Assignment_Type_Configuration”.

Again, I'm JUST getting started with 3.0, but as an observation: you always supported allow some pretty great flexibility for entity/field naming patterns using database first. It seems logical to support the exact reverse of that flexibility when doing model first.

For example, I personally would not use "tbl" as a prefix for each table in my database, but what if that is my company's standard? In order to comply, I need to do database first or manually modify?

I may end up doing database first anyway, not because of this limitation, but because it's the way I normally work. However I think a good long term feature would be to allow equal flexibility regardless of whether you are doing model or database first.

Sorry for the many, many posts.

I would also request a feature of having some control over the primary key, foreign key, and unique constraint keys names that get generated in the DDL.

psandler wrote:

Yes, absolutely. To quote myself from comments in my blog (http://psandler.wordpress.com/2009/12/10/database-standards-and-conventions/):

it may be thin, but underscores force the separation and easy reading of words within a name. In SQL Server (which is by far the database I use the most), names are not case sensitive, and casing is a much bigger factor if you use straight camel casing than if you use underscores. For example, “AssignmentTypeConfiguration” becoming “assignmenttypeconfiguration” vs. “assignment_type_configuration” becoming “Assignment_Type_Configuration”.

Again, I'm JUST getting started with 3.0, but as an observation: you always supported allow some pretty great flexibility for entity/field naming patterns using database first. It seems logical to support the exact reverse of that flexibility when doing model first.

That's a good point. We can't change the setting in the middle of a release, as that would cause problems when a project is opened in different builds, but we'll look into it in the next version.

You can 'cheat' if you want case sensitive behavior for naming btw . Open the file driver.config in the sqlserver driver folder and add: <caseSensitiveElementNames>true</caseSensitiveElementNames> to the <databaseDriver> element.

For example, I personally would not use "tbl" as a prefix for each table in my database, but what if that is my company's standard? In order to comply, I need to do database first or manually modify?

Good point indeed. We totally didn't think of this (as these prefixes/suffixes are actually not that great to have): it might be indeed someone is forced to use these prefixes/suffixes.

I think we'll add patterns for this in the next version.

I may end up doing database first anyway, not because of this limitation, but because it's the way I normally work. However I think a good long term feature would be to allow equal flexibility regardless of whether you are doing model or database first.

Yes, you're absolutely right.

psandler wrote:

Sorry for the many, many posts. I would also request a feature of having some control over the primary key, foreign key, and unique constraint keys names that get generated in the DDL.

The problem is that they have to be unique and have to fit within the maximum length some databases state, so often within 30 or so characters. To avoid clashes with Fk's already in the db (which aren't imported) we generate a unique key based on a guid. This isn't ideal from a readability point of view, but it's otherwise a bit hard to produce unique constraint names for constraints and stay within length limits...

Sweet, my first 3.0 feature request that will make it into the product. I agree that it's not urgent.

I think the FK/PK/UC naming flexibility should be supported in the long term, although I understand the problem, as not only do different database have different limitations, you would have to support uniqueness within each database (not across databases). This could get tricky if entities are moved from one database to another. Maybe this is something that can be handled via validation?

However making model-first as database (and DBA) friendly as possible can only benefit the product. Certain types of developers/DBAs take big issue with a framework making any kind of decision for them. There are not many cases where a human-readable PK/UC/FK name is actually useful, but having naming standards for all database objects is a generally good practice IMHO.

psandler wrote:

Sweet, my first 3.0 feature request that will make it into the product. I agree that it's not urgent.

I think the FK/PK/UC naming flexibility should be supported in the long term, although I understand the problem, as not only do different database have different limitations, you would have to support uniqueness within each database (not across databases). This could get tricky if entities are moved from one database to another. Maybe this is something that can be handled via validation?

The main issue is the relationships which aren't in the relational model data read from the db. If you select a subset of the tables, not all FKs are read. We can't validate against these, as we don't know them . As names can't always be longer than 30 chars, using names of both tables with field names is a bit of a problem, so creating unique names is hard without artificial naming like using guids (although they indeed look cryptic)

However making model-first as database (and DBA) friendly as possible can only benefit the product. Certain types of developers/DBAs take big issue with a framework making any kind of decision for them. There are not many cases where a human-readable PK/UC/FK name is actually useful, but having naming standards for all database objects is a generally good practice IMHO.

I agree, we'll look into this for the next version

psandler wrote:

However making model-first as database (and DBA) friendly as possible can only benefit the product. Certain types of developers/DBAs take big issue with a framework making any kind of decision for them. There are not many cases where a human-readable PK/UC/FK name is actually useful, but having naming standards for all database objects is a generally good practice IMHO.

+1

The generated PK and FK names could be verified during the validation of the entity model and if they are too long or already exist the user could adjust them manually.