Manual mapping
In a previous post I’ve warned about the not so automatically behavior of the automatic mapping. However, I can’t blame the manual mapping for the same degree of inconsistency. I mean, boy, that’s as manual as it gets!
Take a manually mapped attribute and have a look at its source tables. Now drop the attribute from one of these tables (on database and Catalog level) and try to run a report which used that table.
On the one hand, MSTR knows from the attribute definition that it can include that table into the SQL. On the other hand, it should know from the table definition, as updated in the Warehouse Catalog, that the column is no longer there, but such a small detail doesn’t have enough force to deter the SQL Engine. So it simply writes the SQL as if nothing had happened, and the only error you get is from the database (i.e. a11.attribute_id does not exist).
So, if you aren’t doing this already, don’t forget to inform the manually mapped attribute that one of its source tables decided to discontinue their relationship, next time you indulge in such data model changes.
Dropping the Attribute is change to schema Object. The rule is if you change anything under the schema objects folder update schema. also if you are dropping the column from the table and the desktop is not indicating have your conflict check setting for the catalog option and desktop preferences. you may have turned of the checks in the system that tell if if there is an issue irrespective if it manual attribute or not
Schema update does not help in this case. Actually I’m not even sure it can influence manual mapping. If it should have such an influence, then this example is a replicable bug. The only effect I know of, regarding manual mapping, is that if you modify the source list (add/remove a source table) and you want the SQL Engine to include your changes in its output, you must of course perform a schema update.
So far the Warehouse Catalog did not warn about conflicts when the attribute or fact had at least one source table available besides the one you are removing. It loses its temper only when you are trying to remove the column from the last (only) source table.
There’s maybe some confusion about what it means to “map schema objects to the new tables automatically.” I can see how it would be assumed to mean “synchronize schema objects with changes to the warehouse catalog.” But it really means exactly what it says — add mappings for new tables/columns. The dialog in fact says nothing about deleting mappings automatically.
Subtle semantic point, yeah, but that’s my understanding of it.
To answer the question of whether a product behavior is desirable or not, I’ll usually try to imagine a situation where the current behavior is better than the proposed alternative. One reasonable counterexample is: suppose an attribute requires a complex ApplySimple to map onto a table. Now suppose a user accidentally removes that table from the warehouse catalog and saves the changes. If the WH catalog removed attribute mappings, the complex form expression would be deleted also. Then the user realizes the mistake, adds the table in again, and has to rebuild the expression (possibly from memory if project documentation is poor).
Since deleting things is irrecoverable, I think it would not be good to have the warehouse catalog ripping chunks out of schema objects — not without some sort of user control.
One can always open a support case to request an enhancement.
@hjh: Thanks for the fine points here!
Now, I can’t help thinking that my article may be interpreted as criticizing. Well, that’s not the case
I just presumed that if I made an assumption regarding the way a function may perform, then it may be possible that others make the same assumption. In our case, I tried to apply automatic mapping behavior (which thankfully does delete mapping automatically) to manual mapping.
I agree that the existing behavior has more advantages in the long run. The only possible enhancement that I can think of, is to let the Catalog inform that the attempted operation affects some objects that are manually mapped to the table.