Fluent NHibernate automapping child class when base already exists in database

Question

I am having difficulty automapping my object using Fluent NHibernate.

I have class called Document for which the table already exist in SqlServer.

Class Packet extends Document and Have a member PacketDefinition.

PacketDefinition has a List of Form (not windows form but my own class) type.

enter image description here

I am trying to automap Packet object using following configuration.

        var mapping = CreateMappings();

        _sessionFactory = Fluently.Configure()
                                  .Database(
                                      MsSqlConfiguration.MsSql2008.ConnectionString(
                                          c => c.Server("machinename\\sql2012").Database("DatabaseName").TrustedConnection())
                                                        .ShowSql)
                                  .Mappings(m => m.AutoMappings.Add(mapping))
                                  .ExposeConfiguration(BuildSchema)
                                  .BuildSessionFactory();

    private static AutoPersistenceModel CreateMappings()
    {
        return AutoMap
            .AssemblyOf<Packet>();
    }

    private static void BuildSchema(Configuration config)
    {
        new SchemaExport(config).Create(false, true);
    }

The problem is when I try to automap Packet class I get error saying

System.Data.SqlClient.SqlException : There is already an object named 'Document' in the database.

I understand that Document table already exists in the database and I don't want to drop it. I tried Ignoring the base class using

AutoMap.AssemblyOf<Packet>().IgnoreBase<Document>();

but then automapping creates all the properties of Document in Packet table too, and that's not good.

If I create a separate database and then try running same code it works as Document table doesn't exist in that database. I don't want to drop existing table as there is lot's of data in it.

score 0 · Answer 1 · answered Mar 12 '13 at 15:01

If I understand correctly, you are trying to avoid dropping your Document table because "there's lots of data in it".

I'm not aware of any way to do what you want. FNH and NH do not have any data migration functionality (AFAIK), and I think you are just fighting the system when you try to use it this way.

If it's just one table, maybe you could do something simple like export it to a flat format like a CSV file, then let FNH rebuild the schema, and then import the data again.

However, this approach may not scale well as your schema evolves and gets more complicated.

On my project, we were able to dodge this issue because we first save our data in proprietary binary files that our legacy programs also use, so we can just re-import all our data when our schema changes. But that's hardly ideal for the majority of projects.

Thanks for reply. You are correct, I don't want to drop existing table as it contains lot's of data. Also my database schema is awfully complicated so exporting the data and re-importing can result in a big mess for lot's of customers. Does EF handle this any better? — Mayank, Mar 12 '13 at 15:05
I have no experience with EF, but read recently that EF has better migration tools. But they also said the mapping and schema generation is not nearly as good as FNH/NH. Maybe you should post another SO question asking about data migration strategies with FNH/NH schema generation. — Tom Bushell, Mar 12 '13 at 15:29

Fluent NHibernate automapping child class when base already exists in database

1 Answers1