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.

Conclusion

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.

Posted by Mitchel on Tuesday, March 23, 2010
Tags: DotNetNuke, DotNetNuke Administration
 

Comments

I second that ;)

By Ian Robinson on Tuesday, March 23, 2010 at 8:55 PM

I would disagree with you when it comes to the primary purpose for objectQualifiers existence. It can be very useful when you have two separate applications that are part of the same site. For instance, I'm not happy with any of the available E-Commerce solutions for DotNetNuke and I sometimes combine an independent E-Commerce site along with DNN. For the DNN piece I use an objectQualifier to ensure there's no conflict between the tables. There are many other cases like this where it can be useful.

And, if a module developer doesn't make the effort to support objectQualifiers in there module, chances are they don't have a very complete understanding of good module development practices for DNN and it might not be a good idea to use their module as they might expose you to security risks or other problems.

By David O'Leary on Tuesday, March 23, 2010 at 9:36 PM

Yeah... i'm going to second David's comment. I see the objectqualifier as an out of the box way to help obscure your database objects. It may have started as a means to allow single database/multiple portal installs, but it's morphed into something that helps obscure my systems. At least that's how I look at it.

By Scott Allender on Wednesday, March 24, 2010 at 7:39 AM

Couldn't agree more with Mitch. I've used them several times over the years and they are just a big pain in the rear.

By erik on Wednesday, March 24, 2010 at 7:44 AM

@David and Scott,

Good point there as well, but my same counter point comes true, why introduce a dependency and share a database with two completely separate systems? Why tie the recovery model of each system together?

By mitchel.sellers@gmail.com on Wednesday, March 24, 2010 at 9:49 AM

As a DNN module developer, a large number of our support issues have to do with the ObjectQualifier, but I do see the value in them for certain situations. But on the whole I agree, Mitchel, it's just better to avoid them if you can.

@David: You mentioned that you didn't like any of the available eCommerce modules for DNN. My company just brought a new DNN eCommerce module to market that you might want to check out: http://www.dnnspot.com/Modules/DotNetNuke-Shopping-Cart

By Kevin on Wednesday, March 24, 2010 at 12:49 PM

>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

With DNNBackup you can backup with one 'Object Qualifier' and restore with the same, none or a different one. So, trivial :)

By Horacio on Wednesday, March 24, 2010 at 2:32 PM

@horacio,

I'm not going to comment on specifics here as this is not the time or the place, but the method to do this is a full database find/replace operation, through tables, views, stored procedures and more. Even with a tool to do the job, you cannot just "viola" be done with it without loads of proper testing.

By mitchel.sellers@gmail.com on Wednesday, March 24, 2010 at 2:39 PM

Hi Mitch,
Manually, yes. However, the tool works in a different way (it's "viola", there is no find & replace).
I don't want to write/explain more and make it appear like I'm "advertising"...
Thanks,
H.-

By Horacio on Wednesday, March 31, 2010 at 1:55 PM

Name (required)

Email (required)

Website

CAPTCHA image
Enter the code shown above:

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.

Friend of RedGate

www.datasprings.com - DotNetNuke ModulesICG

Click here for advertising information.

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.