Rule driven alias - performance issues for maintenance

[fleaster]

Hi all,
I have been creating a rule on the element attribute control cubes to generate alternate aliases - the rule works fine on 6 out of 7 of the dimensions, however, on the last one (which also happens to be the biggest one!), it has encountered performance issues whenever the dimension is being updated to modify or add new elements (however the user display in subset editor is fine).

The rule basically converts "desc+code" (static value) to "code+desc" (rule driven)
e.g. "0916999000 (Operating Expenses)" to "0916999000 Operating Expenses"

...so at this stage am consdering whether there is something wrong with my rule, whether my dimension has been corrupted (although I have tried adding/deleting a dummy element to "reset the index" and checked for duplicates) or whether the dimension is simply too large and I need to use TI to update to a static alias.

If anyone has any ideas, plz let me know Thanks!

-Matt

P.S. yes I realize storing the main alias in a"desc+code" format is probably not the best practice, but unfortunately it was a legacy design embedded in almost all processes

Code: Select all

#========== }ElementAttributes_Account cube rules ============

FEEDSTRINGS;

# if desc+code is not blank, and the element string (enclosed in brackets) can be found in the desc+code
# ...then derive code+desc alias from desc+code
# ...else assign the same  desc+code attribute  to  code+desc alias

['code+desc'] = S: If( AttrS('Account',!Account,'desc+code')@<>''     &  Scan( '(' | !Account | ')' , AttrS('Account',!Account,'desc+code'))<>0 ,
    # true
   !Account | ' ' | Trim( Subst( AttrS('Account',!Account,'desc+code'),1 , Long(AttrS('Account',!Account,'desc+code'))-Long(!Account)-3 ) ),
    # false
    AttrS('Account',!Account,'desc+code')
                            );

[declanr]

I have previously used rules to create aliases and encountered numerous issues; now as best practice I just always do it via TI. As long as you don't have users manually adding elements into the dimension you can run the alias part of your TI within the TI that adds new elements and you should never have an issue with it getting out of sync. I would say the only reason to use a rule would be if users manually add elements to the dimension and sometimes forget the alias.

[lotsaram]

I understand the allure of using rules for aliases and did this myself many years ago but it isn't a good practice, as well as poor performance you can also run into conflict and update issues and issues on server restart with aliases not being recognised depending on order of evaluation from the underlying fields. Much better to set alias values in a TI process.

[EvgenyT]

Given that string rules are never cached in memory and evaluated every time, I would not go down that road.

[BariAbdul]

Lastly,Numeric attributes also treated as string attributes in these control cubes!

[mattgoff]

As long as you don't have users manually adding elements into the dimension you can run the alias part of your TI within the TI that adds new elements and you should never have an issue with it getting out of sync. I would say the only reason to use a rule would be if users manually add elements to the dimension and sometimes forget the alias.

Or have the alias generation in a separate process that runs on a schedule. I, like the others, migrated away from rule-driven aliases, but they are not derived from another source; they're added or edited manually. To avoid missing or desynchronized aliases, I just added the script to my nightly "maintenance" chore.

Matt

[declanr]

As long as you don't have users manually adding elements into the dimension you can run the alias part of your TI within the TI that adds new elements and you should never have an issue with it getting out of sync. I would say the only reason to use a rule would be if users manually add elements to the dimension and sometimes forget the alias.

Or have the alias generation in a separate process that runs on a schedule. I, like the others, migrated away from rule-driven aliases, but they are not derived from another source; they're added or edited manually. To avoid missing or desynchronized aliases, I just added the script to my nightly "maintenance" chore.

Matt

True, I wasn't suggesting I would do it... just suggesting that is the only reason I can think of why someone would.

[fleaster]

Hi all, thanks for the feedback - am surprised at the overwhelming negative feedback on using rule driven aliases

...in any case, I realized why my original rule had bombed out - it was because I was basing the rule driven Alias on another Alias - big mistake :p

In any case, I think we'll end up going down the route of just loading a base description attribute, then running an overnight TI process to populate all the derived Aliases