Case sensitivity when altering a type definition

Topics: Customizing Orchard, Troubleshooting, Writing modules
Oct 10, 2012 at 12:02 PM

Hi

I've just started getting to grips with Orchard in the past day or so, and have stumbled upon an issue that I couldn't find else where in the discussions:

Whilst creating a Migration for a new Type, I inadvertently got the casing wrong for the AutoroutePart (I had typed AutoRoutePart). After the Migration ran, the new content type was visible under Content>Content Types as expected.

Clicking edit on the new content type showed that the new route settings had been added to the content type (despite the casing being wrong in the migration).

However, when I clicked Save, an exception was thrown in \ContentManagement\MetaData\Builders\ContentTypeDefinitionBuilder.cs on line 66 (Sequence contains more than one matching element).

I believe this to be caused by a combination of the incorrect casing in the Migration file, and the correct casing provided by the Orchard front end resulting in the same part definition being defined more than once.

Steps to reproduce:

  1. Create a clean install of Orchard
  2. Create a new module (in my case it was called Pluralsight.Movies)
  3. Create a Migration file for this module as set out below
  4. Run the solution and go to the Dashboard and active the Pluralsight.Movies module
  5. Create a new movie type content and publish it. Note that the URL for the new piece of content is not as defined in the Migration file (which is expected as the casing was wrong)
  6. Now go back to the dashboard and edit the Movie Content Type. Note that the Autoroute settings are populated as attempted in the Migrations file.
  7. Click the save button and the exception will be thrown.

Migrations File:

using System;
using System.Collections.Generic;
using System.Data;
using Orchard.ContentManagement.Drivers;
using Orchard.ContentManagement.MetaData;
using Orchard.ContentManagement.MetaData.Builders;
using Orchard.Core.Contents.Extensions;
using Orchard.Data.Migration;

namespace Pluralsight.Movies {
    public class Migrations : DataMigrationImpl {

        public int Create() {
            ContentDefinitionManager.AlterTypeDefinition("Movie", builder =>
                builder.WithPart("CommonPart")
                .WithPart("TitlePart")
                .WithPart("AutoRoutePart"));

            return 1;
        }

        public int UpdateFrom1()
        {
            ContentDefinitionManager.AlterTypeDefinition("Movie", builder =>
                builder.WithPart("BodyPart")
                .Creatable()
                .Draftable());

            return 2;
        }

        public int UpdateFrom2()
        {
            ContentDefinitionManager.AlterTypeDefinition("Movie", builder =>
                builder
                    .WithPart("BodyPart", partBuilder =>
                        partBuilder.WithSetting("BodyTypePartSettings.Flavor", "text")) 
                    .WithPart("AutoRoutePart", partBuilder =>
                        partBuilder
                        .WithSetting("AutoRouteSettings.AllowCustomPattern", "true")
                        .WithSetting("AutoRouteSettings.AutomaticAdjustmentOnEdit", "false")
                        .WithSetting("AutoRouteSettings.PatternDefinitions", "[{Name: 'Movie Title', Pattern: 'movies/{Content.Slug}', Description: 'movies/movie-title'}, {Name: 'Film Title', Pattern: 'films/{Content.Slug}', Description: 'films/film-title'}]")
                        .WithSetting("AutoRouteSettings.DefaultPatternIndex", "0")));

            return 3;
        }
    }
}

 

Expected behaviour:

This is how I imagined the expected behaviour:

  • The Autoroute settings should not have been populated in the front end of Orchard as they were incorrectly defined in the Migrations file, and were not called upon when I viewed the newly created Movie content
  • Saving the Movie Content Type should not have resulted in an exception as the incorrectly cased key should not have had an impact on the creation/ alteration of the correct key

 

Can anyone else replicate this? And if so, is this an issue that need to be resolved? I am of the opinion that either the keys should be 100% case sensitive, or 100% case insensitive; what I have experienced here appears to have been a combination of the two, which has resulted in the instance of Orchard I was developing on becoming unstable.


Coordinator
Oct 10, 2012 at 4:54 PM

Can you please create this as an issue rather than a discussion?