Uploaded image for project: 'Drools'
  1. Drools
  2. DROOLS-2962

Incremental and Non-Incremental evaluation instead of sequential mode.

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • None
    • NEW
    • NEW

      While Drools supports sequential mode at the engine configuration level. We should move this to a unit and rule level.

      We should enhance this work too. Right now Drools evaluation is either fully incremental or non-incremental if the kbase is set to stateless.

      Sequential mode current means two things.
      1) Rules evaluate and fire in load order.
      2) Rules are non-incremental.

      By default now all rules are load order anyway. If we simply supported a @NonIncremental or @Incremental(NO) attribute on a unit, then it's behaviour would be the same as sequential is now, but scoped to the unit. I believe this is true, but I'd like this verified (challenged).

      As with existence/data driven, this is the default for the unit's rules. A unit may override with the opposite configuration.

      This means a unit can be mixed incremental and non-incremental.

      Existence or Data Driven annotations for non-incremental do not make sense, and their combination should throw an error, as explained below.

      Instead a non-incremental rule should have control on whether it is to be re-evaluated and fired, each time the unit is entered. At first glance this behaviour looks very similar to Existence Driven, however the choice not to allow @ExistenceDriven + @NonIncremetal is due to the lack of symmetry. You could not combined @DataDriven + @NonIncremental. That lack of symmetry may break intuitive learning, if it's not kept clean.

      If an alternative annotation is introduced - such as @OneShot|@EvalAndFireOnce|etc. We should make sure it fits intuitively and cleanly with how we explain @ExistenceDriven. Potentially OneShot rules/units could utilise the shadow network and be removed from propagation after evaluation.

              mfusco@redhat.com Mario Fusco
              mproctor@redhat.com Mark Proctor
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: