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

Reply via email to