March 23, 2010

The DotNetNuke Object Qualifier - Why I Think it is Evil

For those of you that have seen my comments on the DotNetNuke forums, my book, or the forum here on this site, you more than likely have noted my consistent notes that I recommend avoiding the "ObjectQualifier" setting within DotNetNuke at all costs.  Most of the time I have simply put, I don't use it and recommend that you don't either, but have not given a very detailed explanation as to why I'm not a fan.  Below I will share with you what the ObjectQualifier is, why it was created, and why I don't recommend using it.

What is the Object Qualifier

The Object Qualifier is a configuration setting within the DataProvider section of the web.config available in DotNetNuke that allows you to set an optional qualifier that will be prefixed to any and all SQL Server objects that are created as part of the DotNetNuke and module installation process.  Module developers support the usage of this option by including "" at the beginning of the creation of all scripts that are excuted as extensions are installed.

Why it was Created

The DotNetNuke object qualifier, as to the information that I have been provided, was created for those that wanted to get the "most value" from hosting plans that offered limited support for SQL Server databases.  The Object Qualifier was introduced to allow you to effectivly install multiple DotNetNuke installations within the same physical database.

Why I Do Not Use It

There are a number of reasons that I do not use an ObjectQualifier within my installations.

Data Recovery Model of Shared Databases

The first and primary reason that I do not use an ObjectQualifier is that more than anything I don't want to share a database across multiple sites anyway.  We already recommend that people don't use Multi-Portal installations due to performance, data recovery, and other reasons, why would we want to mix two entirely separate data models into the same database.

Backups and restores will affect both sites, and the overall recovery model is just plain wrong.

Databases are Cheap

Current hosting plans are easy to come by that have multiple SQL Server databases, one per domain, which allows for a fully separate DotNetNuke installation for each domain.  This is the recommended best practice anyway, and avoids any issues with a shared data model

No Guarantee that Third-Party Supports It

Although as I mentioned the Object Qualifier is something made available to third party extension developers, you have not guarantee that they fully support the usage of an Object Qualifier.  If using an Object Qualifier with a third-party module that doesn't support it can result in very un-expected site performance as well as errors and even worse site outages depending on the nature of the problem.

Cannot Easily Change Your Mind

Lastly, once you decide to go with an Object Qualifier, you are pretty much stuck with it.  Although theoretically possible to disable it, it is not a trivial task, and results in a lot of effort as all tables, functions, and stored procedures must be renamed as well as items internal to individual stored procedures.  There is not a clean/clear process to reverse should you have issues with it in the future.


I hope this serves as a bit of an overview as to why I don't recommend the use of Object Qualifier and why I am always recommending against it!  Feel free to share comments below.

tags: DNN, DNN Administration
comments powered by Disqus

Content provided in this blog is provided "AS-IS" and the information should be used at your own discretion.  The thoughts and opinions expressed are the personal thoughts of Mitchel Sellers and do not reflect the opinions of his employer.

Content Copyright

Content in this blog is copyright protected.  Re-publishing on other websites is allowed as long as proper credit and backlink to the article is provided.  Any other re-publishing or distribution of this content is prohibited without written permission from Mitchel Sellers.