- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-15-2014 06:09 PM
Hi All,
I have added a new field to cmdb_ci with a label of "Common Name". This is because we use Discovery, which populates the Name field in a way that does not always comply with our naming standards. Most of the time it is ok though, so I have a calculated field value on the Common Name field, along the lines of "current.u_common=current.name;". This means I can override it on any table class with a different new naming standard. This seems more efficient that using business rules to do the same thing because of the neatness of overrrides.
The issue I found was, what if the Name field has an override on it to perform it's own calculation (i.e. now there is a calculation based on another calculation). How do I ensure that it's calculation runs before that of the Common field? Unlike business rules, there is no obvious Order number to calculations. If there is no predicable order between calculated fields, then can I at least be assured that calculated fields all run before any business rule does (or visa versa). If that is at least known, then I may have other options.
Is there any advice our there in terms of best practice or healing battle scars from this sort of issue?
Thanks
Howard
Solved! Go to Solution.
- Labels:
-
Service Mapping
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-15-2014 06:52 PM
Well, to quote a friend, Capa JC, Calculated Fields are evil!!!
Calculated fields are calculated every time a row is read, whereas the BR will only run when needed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-15-2014 08:32 PM
Hahaha! I totally agree that calculated fields are evil. I once attempted to create a calculated field on the User table to display the number of direct reports that User had (user records looking up other user records) - I unwittingly triggered an infinite recursive loop and crashed the entire instance instantly. Just saying - calculated fields are evil - and could definitely do with some documentation.