The rulebase level stuff is essentually what you get when you use a cache/map - no issues or questions there, and you are probably right. It should be possibly by just loading different versions of the rulebase into a named cache. The question is what do we need to add to the tool to support this that a user can't do already? ideas?
But grandfathering individual rules came up so often I thought it was worth exploring the possibility of including it in the syntax itself (I would rather not, but am prepared to be convinced). On 11/30/06, Geoffrey Wiseman <[EMAIL PROTECTED]> wrote:
For our purposes, we'd likely want to version an entire 'set' of rules (ruleset or more likely: rulebase), so that each set could be tested before deployment as a unit, for the simplicity therein - if there were a significant performance/load/memory difference in applying versions at the rule level rather than, say, rulebase level, we might consider it, but otherwise, there's a simplicity and testability of knowing that there's only one combination to test per version, rather than trying to make sure that each rule has the same condition, or understanding how the conditions interact to result in one 'version' of the rulebase. On 11/30/06, Michael Neale <[EMAIL PROTECTED]> wrote: > > Have talked to a few people about this, so I thought it was worth a > write up in the wiki: > http://wiki.jboss.org/wiki/Wiki.jsp?page=RulesGrandfather > > Basically am fishing for ideas of building in grandfather capability > into rules declaratively. (ie 2 different versions of the same rule > available, used depending on the data). This is related to but seperate from > repository based effective dating. > > Please reply with any thoughts (or put notes on the wiki). > > Michael. > -- Geoffrey Wiseman