Hi Andre, I've got something I'd like to bounce of you if you have a moment.
I've found a behavioral change in how a database design refresh/replace works from R5 to ND6, and it's causing a fairly aggravating problem for me.
- I have a template database that is a central code repository -- let's call it "MasterDesignElements".
I have an application that involves a set of 7 other databases that are also templates -- let's call them "Template1" through "Template7". Many of the design elements from "MasterDesignElements" have been copied/pasted into each these, so they will individually inherit from "MasterDesignElements".
Why this is nice
- This application has been deployed over a few hundred instances, so there are ~300 x 7 = 2100 databases hanging out on a server set to inherit their database designs from the TemplateX dbs. This is distributed rollouts at its finest -- By changing an element in "MasterDesignElements" and running a load design all 2100 instances of the element will change. Great stuff! This is a huge benefit for anybody working with multi-db apps in Domino.
Here comes the problem
- After a few months, one of the TemplateX databases (and its 300 children) needs to have its own specific version of one of those design elements (e.g. "Public Access" needs to be enabled, where it wasn't before). You want to keep the same name on it so that all of your other code referencing the element will still work. So you:
1. Open the TemplateX database
2. Select the design element you want to have "stand on its own"
3. Remove its specific inheritance (i.e. clear out the "MasterDesignElements" reference).
4. Edit the design element.
5. Turn on Public Access and save the element.
Here's the problem - these changes will NOT push to the 300 child databases. Their instantiation of the element will still be attempting to update itself from the MasterDesignElements database.
It gets worse
- If you then delete the element from the TemplateX database, this change too will NOT push to the 300 child databases. They will still have the instantiation of the element from before, still trying to update itself from the MasterDesignElements db!
What's more, if you attempt to perform a *Replace* design from TemplateX, the instantiation will still exist.
- The ND6 Designer Help states:
- Individual elements whose template is inherited (that is, if "Inherit from the design template" is selected in the Design Properties box for the element)
- The Replace Design command makes a database identical to a template and is the only way to distribute design changes if the database doesn't inherit its changes from a template.
but then later states:
- Components that are not replaced during Replace Design
The following components are not changed during a Replace Design procedure:
Caution An element with inheritance set is not replaced even if its design is not protected from updates (that is, if "Prohibit design refresh or replace to modify" is not selected).
In a nutshell, when an ND6 design refresh/replace encounters a design element set to individually inherit, it will attempt to refresh it from that template without checking first to see if that element should even exist anymore according to the database's template.
So bottom line - the only way to remove an individually inheriting element from any database is to do it manually. A design refresh will, however, happily add one of these elements to a db -- it will just never remove it, or ever remove the individual inheritance if you happen to have turned that off. Essentially once it's there, it's there forever.
This is a complete change in handling from R5. R5's Designer Help does not list individual design elements as not being updated, and does not have the cautionary statement either. R5 always checked to see if the design element existed in the database template first, added or deleted it as need-be (or set/removed the individual inheritance), and then would update it from the individual template specified if there was one.
This is a big problem for anybody building multi-db apps where code re-use is heavy. Another example: I recently merged a few libraries together in the MasterDesignElements database, distributed that to the TemplateX dbs, and then deleted the old versions from the TemplateX dbs. The child databases ignore my deletions, and now have orphaned copies of the original libraries that I will have to remove by hand.
I've opened a PMR for this (#13475,442,000 if you're interested), but support is coming back with "working as designed". I didn't go into quite this level of detail (or emphasize the regression aspect versus R5) when I initially opened it, though, so I'll send this along to see if it makes a stronger case.
Thanks for taking the time to read this -- I definitely don't take your presence here for granted, but I'd love to hear your feedback.