Page 1 of 1

Rule driven alias - performance issues for maintenance

Posted: Thu Nov 13, 2014 7:25 am
by 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')
                            );

Re: Rule driven alias - performance issues for maintenance

Posted: Thu Nov 13, 2014 7:39 am
by 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.

Re: Rule driven alias - performance issues for maintenance

Posted: Thu Nov 13, 2014 8:05 am
by 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.

Re: Rule driven alias - performance issues for maintenance

Posted: Thu Nov 13, 2014 11:26 am
by EvgenyT
Given that string rules are never cached in memory and evaluated every time, I would not go down that road.

Re: Rule driven alias - performance issues for maintenance

Posted: Thu Nov 13, 2014 12:30 pm
by BariAbdul
Lastly,Numeric attributes also treated as string attributes in these control cubes! :D

Re: Rule driven alias - performance issues for maintenance

Posted: Thu Nov 13, 2014 4:08 pm
by mattgoff
declanr wrote: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

Re: Rule driven alias - performance issues for maintenance

Posted: Thu Nov 13, 2014 4:15 pm
by declanr
mattgoff wrote:
declanr wrote: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.

Re: Rule driven alias - performance issues for maintenance

Posted: Thu Nov 13, 2014 11:10 pm
by 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