0

We have issues with too much red tape when dealing with changes to the database. Perhaps most strangely, this red tape applies to in-house developed testing tools that use a database schema that is never put into production. We can get changes applied to our primary testing environment within a few days but i can take weeks to get it applied to other testing environments. This is wrecking havoc on our use of NHibernate because if the updated mapping is applied to older databases, things stop working entirely. We don't remove columns, only adding more when appropriate. Due to occasional bugs or general enhancements, we keep all versions of our testing tools up-to-date.

Is there a way to get NHibernate to gracefully ignore a mapped column if it doesn't exist in the database (perhaps setting default values on the objects)?

We use hbm.xml files right now.

scott.smart
  • 538
  • 5
  • 16

1 Answers1

0

I think this is more of a source control problem than anything. Typically the database and software versions should go hand in hand. With a good branching and merging strategy you shoudln't be running into this. You should always have a version of your source that ties to what's actually in production (in my opinion).

In our situation when a version of the software/database is released we have a release branch that corresponds to that version. If a software change needs to be made where a database column was added for example we would have a development branch where the work was done and when it was ready to release in production we would then create a new release branch that corresponds with what you just installed in production.

If bug fixes needed to be made to a production version you could branch off of the release branch to make the bug fix. Once tested and deployed to production you would then merge the changes made in the bug fix branch back to the release branch to again represent what was in production. You would then also in turn merge any changes from that release branch to your "latest"/main branch.

There are some great guides on various branching and merging strategies here: http://vsarbranchingguide.codeplex.com/releases

But to answer your specific question I don't think there is a great way of doing this. If it's in the mapping nhibernate will query it and thus causing errors.

Edit:

There are things you can do in NHibernate to only look at certain columns. For example on updates and inserts you can set the mappings to do dynamic inserts and updates:

(7) dynamic-update (optional, defaults to false): Specifies that UPDATE SQL should be generated at runtime and contain only those columns whose values have changed.

(8) dynamic-insert (optional, defaults to false): Specifies that INSERT SQL should be generated at runtime and contain only the columns whose values are not null.

Above taken from: http://nhibernate.info/doc/nh/en/#mapping-declaration-class

Also in nhibernate queries you can specify the specific columns you want to query:

IList selection =
    session.QueryOver<Cat>()
        .Select(
            c => c.Name,
            c => c.Age)
        .List<object[]>();
hazzik
  • 13,019
  • 9
  • 47
  • 86
Cole W
  • 15,123
  • 6
  • 51
  • 85
  • Thanks, for the info. Unfortunately, I am not allowed to branch this particular code. As I stated, these are in-house testing tools. Neither the tables in question, nor the programs themselves go to production. In effort to maintain conformity of testing, we maintain only one version of the tools that anyone can access. While I personally would love to do a little branching and versioning (would make my life so much easier), I cannot :( The main problem is that the DBAs don't seem to be condemned to a fate of keeping Quality Assurance up-to-date and I was hoping to find an NHiberate fix. – scott.smart Feb 21 '14 at 20:16
  • @scott.smart Added an edit to my post but somehow I doubt this will help you either. – Cole W Feb 24 '14 at 18:20