Prevent renaming and Case Conversion

I'm not sure if a setting on the Model is a possibility (for example, Teleriks UnderScore, Case, and Plural settings), but if it is not, would you be able to provide me with some information on where I can find the code that you use to rename the Tables and convert the case on the Tables & Columns? I really need to preserve the case of my columns and prevent the incorrect renaming of tables. i.e. EmployeeTCS gets renamed to EmployeeTc. I know they can be renamed in the designer, but this is not a suitable option for us.

\I'm loading the XML from the .lsmodel and merging missing information that I need from the SQL Schema, but the renaming is throwing monkey wrenches at me.

You can turn off case conversion by implementing an IDesignTimeNamingStrategy. There's no hook in that interface to override incorrect singularisation, but we can add one for you. I'm a bit curious as to why renaming in the designer is not a suitable option for you though?

To implement IDesignTimeNamingStrategy to disable case conversion:

• Create a Class Library project which references the LightSpeed Mindscape.LightSpeed.Generator.Integration.Dsl.Mapping DLL.
• Add a class which implements Mindscape.LightSpeed.Generator.Extraction.IDesignTimeNamingStrategy.
• Implement the methods to return tableName, columnName and defaultColumnName as appropriate.
• Implement the UseClrNamingConventions property to return false.
• Build the DLL.

Using a design-time naming strategy in a model is not exposed in the UI so you need to edit the XML directly:

• Open your model in the LightSpeed designer and go to the Model Explorer (View > Other Windows > LightSpeed Model).
• Right click the Model node in the tree and choose Add New Design Time Assembly.
• Enter the path to your strategy DLL.
• Save and close the model.
• Open the .lsmodel file in a text editor.
• Add the following attribute to the <model> element: designTimeNamingStrategyType="MyNS.MyStrategy" (where MyNS.MyStrategy is the namespace-qualified name of the strategy type). You don't need to assembly-qualify it because LightSpeed automatically looks in assemblies listed in the Design Time Assemblies folder.
• Save and close the .lsmodel file.

As I said this will not override singularisation but we can add that hook for you, but we would be interested to understand your scenario first! Thanks!

We make a lot of changes to the database and want the model to maintain the column order defined in the database, so instead of updating the model and moving the columns around, we just delete it and regenerate it. It would be too time consuming and error prone to update the names every time we did this.

Would it be possible to preserve the underscores in table names with the new hook that you proposed? Thanks for the quick response and solution!

Are there any hooks that we could use to modify the .lsmodel file as it is generated? Is there a way to control the model generation (add/remove tables, execute code when a table is added, etc...) using a visual studio extension?

Yep, I'll keep the underscore issue in mind.

We don't currently have any generic hooks to modify the .lsmodel file as it is generated or updated. It's something I've thought about, but it's such a niche requirement we can't really justify it. I'd be fascinated to hear how you'd use such hooks though! If you are really determined then you might be able to interact with the model using the DSL Tools (aka Visualisation and Modeling SDK) APIs, notably Store.EventManagerDirectory -- but you would be working with undocumented ways into the .lsmodel and we would not be able to offer you any guarantees that things wouldn't break!

We have now added a new interface (in the designer Mapping DLL) named IOverrideClrConventions. At present this has just one member, ShouldSingularize. Implement this to indicate that an entity name such as EmployeeTCS should not be singularised.

You should implement this interface on the same class as IDesignTimeNamingStrategy -- effectively you should think of it as an extension to that interface, but extending it would have been a breaking change for existing implementations.

Underscores are now preserved if UseClrNamingConventions is false, so you won't need to do anything extra for that. (They were already preserved for property names, just not for entity names, so the new behaviour is actually more consistent I reckon.)

These changes will be in the next nightly build, available from about 1200 GMT. Please let us know if you run into any issues or if the changes don't meet your needs.

Is there any way to provide a relative URL to the DesignTimeAssemply? I want to keep the Strategy dll in the bin directory of the application. I would also like to be able to give the application to another developer without worrying about them having the dll in the correct place.

-Application
--bin
---strategy.dll
--Models
---Model.lsmodel

I would like to set the Design Time Assembly Path using "../bin/strategy.dll"

Support for this will be in the next nightly build, available from about 1200 GMT. Paths will be tried relative to the .lsmodel file as well as the current directory.

Wow, you are amazing! Thank you for the great support and amazing turn around time. I have never dealt with a company that had support anywhere near this calibre!

This is still changing the Case on Foreign Key columns and renaming my Primary Key Column to Id. Is there a way to leverage the Naming Strategy to prevent these cases? I would like to keep the entity as close to, if not identical to the database conventions to prevent cofusion (for both our developers and clients).

^^ I'm with you. If you look at the thread I started about this, you'll see a sample project which works 99% of what you ask. The primary key is always 'Id'. I would like to change this too, but I guess this is not an easy fix for LS.

The identity of a LightSpeed entity is always the Id property. This is defined in the Entity<T> base class and cannot be changed. Note that we do not change the names of columns. You can still have your database column called CustomerId or whatever and we will map it to the Id property.

If you want a property which always reflects the Id but has a different name, you could create a wrapper property in the partial class:

partial class Customer {
  public int CustomerId {
    get { return this.Id; }
  }
}

However we advise against this because you can't use such wrapper properties in queries -- your application code would need to remember to query on Id rather than CustomerId which would be confusing.

I'll look into the foreign key field naming, but can't promise anything. LightSpeed expects foreign key fields on the CLR side to be named XxxId where Xxx is the association name, and requires you to set Key Property Reference to override this. (Once again, columns can be named anything you like; the convention is required on the CLR side, not the database side.) So naively preserving a name like xxx_id would not suffice because you would still need to manually enter the Key Property Reference to tell LightSpeed that you were using a nonconventional field layout. I'll see whether we can automate setting up KPR but no promises.

It appears that the Naming Strategy creates duplicate Properties for Foreign Key Columns that contain "_" in the name. These appear to store their values in different local variables, so I'm not sure what would happen when saving. If they have different values which one wins? Is there a way to prevent this?

The backing fields also appear to be missing the Column Attribute that maps them back to the SQL Column with the "_".

  [Serializable]
  [System.CodeDom.Compiler.GeneratedCode("LightSpeedModelGenerator", "1.0.0.0")]
  [System.ComponentModel.DataObject]
  [Table(IdColumnName="ObjectUID")]
  public partial class Page_Tab : Entity
  {
    #region Fields

    ...
    private System.Guid _control_PageID;
    ...
    private System.Guid _controlPageId;
    ...

    #endregion

    #region Field attribute and view names

    ...
    /// 
Identifies the Control_PageID entity attribute.
    public const string Control_PageIDField = "Control_PageID";
    ...
    /// 
Identifies the ControlPageId entity attribute.
    public const string ControlPageIdField = "ControlPageId";
    ...


    #endregion

    #region Relationships

    [ReverseAssociation("Page_TabsByControlPage")]
    private readonly EntityHolder _controlPage = new EntityHolder();
    ...

    #endregion

    #region Properties

    [System.Diagnostics.DebuggerNonUserCode]
    public Page ControlPage
    {
      get { return Get(_controlPage); }
      set { Set(_controlPage, value); }
    }
    ...
    [System.Diagnostics.DebuggerNonUserCode]
    public System.Guid Control_PageID
    {
      get { return Get(ref _control_PageID, "Control_PageID"); }
      set { Set(ref _control_PageID, value, "Control_PageID"); }
    }

    ...
    /// 
Gets or sets the ID for the  property.
    [System.Diagnostics.DebuggerNonUserCode]
    public System.Guid ControlPageId
    {
      get { return Get(ref _controlPageId, "ControlPageId"); }
      set { Set(ref _controlPageId, value, "ControlPageId"); }
    }

    #endregion
  }

This looks like you have two separate properties being considered here. I am presuming from what you have said that you only actually have one field in the database and Control_PageID would presumably be what its actually called.

Does this occur when you dont use the naming strategy? If so you will want to have a look into the INamingStrategy implementation to understand why it is returning two separate properties for the one field. If it does actually occur without the naming strategy then could you be able to post the details of the table schema so we can reproduce this here and have a look into what is causing this for you. You can attach a zip file to a forum post using the "Upload a file" button below the preview area.

Jeremy

It only happens with the naming strategy and only happens to foreign key columns that have an "_" in the name. below is the naming strategy that we are using.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using Mindscape.LightSpeed.Generator.Extraction;

namespace Lss.LightSpeedNamingStrategy
{
    public class PreserveDatabaseConventions : IDesignTimeNamingStrategy, IOverrideClrConventions
    {
        #region IDesignTimeNamingStrategy Members

        public string GetEntityName(string tableName)
        {
            return tableName;
        }

        public string GetPropertyName(string tableName, string columnName)
        {
            return columnName;
        }

        public string GetSpecialColumnName(string tableName, string defaultColumnName)
        {
            return defaultColumnName;
        }

        public bool UseClrNamingConventions
        {
            get { return false; }
        }

        #endregion

        #region IOverrideClrConventions Members

        public bool ShouldSingularize(string name)
        {
            return false;
        }

        #endregion
    }
}

The Custom Naming Strategy is not used by Stored Procedures or the Stored Procedure "Result". This combined with the problem with the Foreign Key naming creates too much inconsistency in the resulting Model. Is there a way to get the entire Model to use the same Naming Strategy?

Thanks for reporting these issues.

I have added candidate fixes for both the underscore issue (lack of use of the UseClrNamingConventions property) for both FK's and stored procedures. This will be available in the next nightly build. Let me know if there is anything else you think is outstanding here.

Jeremy

This also resolved an issue with fields containing "_" in stored procedures returning null values. Anyone using the custom Naming Strategy should upgrade to this version. Thanks for the quick turnaround on this, I'll post if we encounter any issues, but so far this looks great!

\Hands down, you have the best support out of any company I have ever dealt with.