customize the database table schema name mapping

[Ohsha]

From GettingStartedwithTelerikOpenAccessORM.pdf:

When using the Use Default Mapping  option,  OpenAccess will automatically build a 
database table schema for an entity based on its properties, and their data types.

From 
http://www.telerik.com/help/openaccess-orm/developer-guide-domain-model-class-mapping-default-mapping.html

By using the Use Default Mapping option, OpenAccess ORM automatically creates a table in the relational part of the model and maps all properties to columns. The specific moment here is that OpenAccess ORM will give default names for the underlying table and columns.

For example, the Customer domain class will be mapped to a table named 'customer'. And the Customer properties will be mapped to columns as follow:

• Id <-> id
• Name <-> nme
• HireDate <-> hire_date

OpenAccess ORM takes care of the columns and table naming. If you want to have full controls over the mapping, then you need to use the Edit Table dialog.

I guess the reason behind this is that database and field names are case insensitive, right?

Still, I want my DB/fields name to be the same as my Domain-class/attribute name. Is there anywhere that I configure it so that it happen automatically, instead of me using the explicit mapping for each and every of my DB/fields?

 Thanks

[Viktor Zhivkov]

Hi Ohsha,

Thank you for your interest in OpenAccess.
Unfortunately the names generated by the default mapping mechanism of OpenAccess cannot be customized, but this functionality is on our TODO list. Currently the only options to improve the table and column names are:

1. Use Fluent mapping (a.k.a Code-First) and

   metadataContainer.NameGenerator.UseModelNames = true

   setting to have class/property names transferred to the table/column names.
2. Use Model-First, but map tables and columns manually as described in Explicit Mapping article.
3. Manually create the database and then use the Database-First scenario to create the domain model. This approach gives you greatest control but requires a bigger implementation effort from your side.

A few more details about the implementation of approach 1. In order to set the UseModelNames setting you need to add the following code in your FluentMetadataSource class:

protected override MetadataContainer CreateModel()
{
        MetadataContainer container = base.CreateModel();
        container.NameGenerator.UseModelNames = true;
        return container;
}

My personal preference and recommendation for development is to use the Database-First approach and fine tune the database schema before mapping it in OpenAccess.
If you need any additional assistance, please do not hesitate to contact me again.

Greetings,
Viktor Zhivkov
the Telerik team

[Ohsha]

Thank you Viktor, 

I'll mark the question as "solved", but please keep in mind that the very incentive for me to use OpenAccess  was to use it as an ERD tool, ie, to define my tables, relations, etc, then to have DML/DB automatically taken care of. 

Hope the coming version of OpenAccess can cover such requirement. 

Thanks

[Viktor Zhivkov]

Hello Ohsha,

I am glad that I have helped you.

I also would like to take the issue a bit further and show you how you can use OpenAccess data model designer as database design tool. There are several steps that have to be taken, but I think this will be enable you to solve your future tasks easier.

1. Enable extensibility of the generated FluentMetadataSource class:
   1. Locate the FluentMapping.ttinclude code generation template. It is located under <OpenAccess Install Dir>\dsl2010\CodeGenerationTemplates\CSharp\Includes\ (by default the path is: C:\Program Files\Telerik\OpenAccess ORM\dsl2010\CodeGenerationTemplates\CSharp\Includes\). If you are using Visual Basic please substitute CSharp with VisualBasic.
   2. Edit line 30 in the template. Add the "partial" keyword to the class definition line, save and close the template:

public partial class <#= metadataSourceName #> : <#= FluentMetadataSourceToken #>

Add new Domain Model

1. Add a new Domain Model to your project. Select empty model on the first page.
2. Go to Code Generation Settings page in the wizard and select Fluent in the Mapping Type. Finish the wizard.
3. Add a new class to the same project in order to extend the generated <Your Model Name>FluentMetadataSource class.
4. Add the following code in the newly created class:

protected override MetadataContainer CreateModel()
        {
            MetadataContainer container = base.CreateModel();

            container.NameGenerator.UseModelNames = true;
            container.NameGenerator.SourceStrategy = NamingSourceStrategy.Property;
            container.DefaultMapping.NullForeignKey = true;

            foreach (var association in container.Associations)
            {
                MetaForeignKeyAssociation fkAssociation = association as MetaForeignKeyAssociation;
                if (fkAssociation != null)
                {
                    fkAssociation.Constraint = null;
                    continue;
                }

                MetaJoinTableAssociation joinTableAssociation = association as MetaJoinTableAssociation;
                if (joinTableAssociation != null)
                {
                    if (joinTableAssociation.JoinTable != null)
                    {
                        var constrainsToRemove = joinTableAssociation.JoinTable.Constraints.Where(c => c.Name == "{no}").ToList();

                        foreach (var toRemove in constrainsToRemove)
                        {
                            joinTableAssociation.JoinTable.Constraints.Remove(toRemove);
                        }
                    }
                }
            }

            return container;
        }



Create a database schema update development-only application - see the attached sample application.
Use the database schema update application to push the changes in the domain model to the database and/or create database schema scripts.

So far this is the best way to enable the scenario that you would like to execute.

The only drawback that I would like to point out is the requirement to use an external application to push changes to the database schema instead of using the context menu Update Database from Model in the RLINQ designer. This step is required because of a limitation in the implementation of the designer.
This issue will be addressed in the future releases of OpenAccess.

If you have any questions or you need further clarifications of the described approach, do not hesitate to get back to us.

All the best,
Viktor Zhivkov
the Telerik team