Options to disambiguate conflicting generated database table names?

JeffMercado

I'm working with a database that has tables named after common .net classes which makes writing scripts awkward. Tables such as Task or Action causes conflicts when using those types in a query.

Can there be an option to rename the entites/properties that are generated for certain tables? (e.g., Task -> DbTask) Or an option to place the generated Table<T> properties in a sub-property? (similar to multi-database connections, but applied to all databases)

Right now, the only way I can get around this is to fully qualify every use of the type (which can be annoying for Task which is used frequently) or nest things in such a way so the table properties are not in scope which isn't always possible.

JoeAlbahari

Automatic pluralization will minimize the issue of property names conflicting with BCL type names (in the connection properties dialog). Have you disabled this feature?

Note that with automatic pluralization enabled, the entity type names themselves will still conflict with BCL type names, but this is easier to deal with:

using System.Threading.Tasks;
using Task = System.Threading.Tasks.Task;
using DbTask = LINQPad.User.Task;

Task<int> task = Task.FromResult (123);
new DbTask { Id = 123 }.Dump();

JeffMercado

I did start using type aliases like that for a while until I hit the limitation of using the generic Task<T> which doesn't work as I'd hoped here. Since an alias only works for a very specific type and cannot be overloaded.

JoeAlbahari

Try adding using directives exactly like in the example above. You won't need to alias generic Task types: Task<T> doesn't create an ambiguity because the table-based Task type is nongeneric.

JeffMercado

Ah ok. It's been a while since I've tried this. It does work now.

Before it would have an error on line 13, I think saying something about not being able to use the generic type parameter on the non-generic Task. And at the time, I did have the System.Threading.Tasks namespace included. I suppose something has changed since then?