This project is read-only.

Widget Not Calling Migrations.Create

Topics: Troubleshooting, Writing modules
Apr 27, 2011 at 6:31 AM

I am creating a very basic widget and using the LatestTwitter Widget as a template. My widget shows up under the Widget category of Modules.
When I enable it the constructor of my WidgetDriver is called, service is injected properly, etc. However, the Create method of the Migrations is never called.
Here is my create method.
public int Create()
            //Creating table LatestTwitterWidgetRecord
            SchemaBuilder.CreateTable("LatestTwitterRecord", table => table
                                                                                .Column("UserNameList", DbType.String)
                                                                                .Column("NumberOfTweetsPerUser", DbType.Int32)

             builder => builder.Attachable());

            ContentDefinitionManager.AlterTypeDefinition("LatestTwitterWidget", cfg => cfg
                                                                                           .WithSetting("StereoType", "Widget"));

            return 1;

Any ideas on things I can check?
As far as I can tell, all files are named properly and it's pretty much an exact replica of the TwitterWidget in the gallery (we are showing different stuff, not limiting to a single user, and a few other tidbits).


Apr 27, 2011 at 6:34 AM

It probably already ran. Try an UpdateFrom1.

Apr 27, 2011 at 9:05 AM

One problem I've had when I copied migrations from another project is that I also copied the namespace and forgot to change it. So if it has the same namespace as another migration that already ran, Orchard will assume it's the same one and won't run it. Check you changed the namespace to your own.

Apr 27, 2011 at 3:55 PM

The namespace is correct. I suspect you are right with the fact that Create was already called.
So, a new question. How do I tell Orchard to pretend like that never happened for a specific module?
Where is the information about a modules version stored in Orchard? I've removed it as a dependency from the App_Data and completely removed the module directory and disabled the module from the asmin panel but Orchard apparently still recognizes the module and the version.
I am writing the module and I want the Create step to be as clean as possible (I don't ever want to have to create a bunch of update steps for what is only a single update). I want a single UpdateFromX function for each version of the module I release.
Ideally I want a way to destroy all Orchard knowledge of this module/widget and have it call Create again, as many times as necessary for me to get it the way I want -- until Version 1 is release, then I'll want to do the same thing but rolling back only to version 1.

When I move on to the next version (2) I will want a way to make orchard go back to thinking it's on version 1 each time I want to run/test my upgrade step.
At that point I think my only option would be to keep restoring the Orchard database from a point where ny module is at version 1?


Apr 27, 2011 at 4:12 PM

I've been deleting the whole database and starting from scratch a lot of the time. This also means you can test the installation and migration process properly from square 0 each time. I've been using Recipies to install all the modules features and populate data. It also means by the time you go live with a site, you've already got a recipe containing exactly what you need for deployment. I know it's a bit laborious, but it's a pretty thorough process once you've got used to it.

The migration numbers specifically are held in the Orchard_Framework_DataMigrationRecord table so you can manually adjust in there if you need to.

Apr 28, 2011 at 4:34 AM

Ok so you have to delete the entire record for it to run the Create script again.
Think it would be possible to allow a user to set the Version field in Orchard_Framework_DataMigrationRecord to 0 and have to cause the Create script to run again?
Currently, setting it to 0 seems to have no effect at all.
This would be beneficial since then, the Id I initially create the module under won't have to change, I can just keep resetting it until I am happy with the code.