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

Proposed feature for ['key'] accessor

    XMLWordPrintable

Details

    • Feature Request
    • Resolution: Done
    • Major
    • None
    • None
    • Ansible Integration
    • None

    Description

      Issue Description:
       
      This is stemming from the return-on-experience work and report we produced on previous request, and specifically as identified here.
       
      In a Nutshell:   I'd like to propose as currently you can do
      event.field == 47
      to allow also something ~like:
      event['field'] == 47
      event["field"] == 47
       
       
      I was explained the rulebook "condition:" is actually modeled after the playbook "when:" conditional.
      I did some further investigations based on provided hints, and convinced me further of this proposal which indeed I'd like now to put forward.
       
      In the Ansible playbook documentation, it is written:

      Ansible uses Jinja2 tests and filters in conditionals

       
      Further, in Ansible playbook documentation, I can find analogous examples of what I'm proposing here for rulebook:

       when: ansible_facts['os_family'] == "Debian"

       
      This confirms the Jinja-inspired syntax works as I'm proposing here as it allows bot dot-accessor and squared-bracket accessor:

      Further, I can find third party tutorials like this one, where the square-bracket accessor is explained with the same semantics as I'm proposing here:

      Let’s look at a few examples and see why it’s not always possible to access data using the dot(.) notation and it’s always possible to access data using the square brackets([]).

       
      Just to put forward some additional details, on the ansible-rulebook side I'd propose something ~like:
       

       
      Of course with some additional modifications I'd plan to do it on Drools side too, to accommodate for this extension!
       
      This would allow for instance given a Kubernetes resource ~like:
       

                - kind: Pod
                  apiVersion: v1
                  metadata:
                    name: hello-pvdf
                    namespace: default
                    uid: 6cd445f4-227d-4e81-957f-88ab08ee0a6c
                    resourceVersion: '35203'
                    creationTimestamp: '2023-04-26T14:50:54Z'
                    labels:
                      app.kubernetes.io/name: hello-pvdf
                      app.kubernetes.io/version: 1.47-SNAPSHOT

       
      To write a rulebook ~like:
       

      name: r1
      condition: event.metadata.labels['app.kubernetes.io/name'] == "hello-pvdf"
      action: ...

       
      Current limitation, in my understanding, is that the / symbol (or other symbols or special characters or unicode in general) is posing a problem, as in the current syntax, that cannot be part of the identifier on the LHS.
       
      Conclusions

      • Square-bracket accessor seems to me idiomatic in Ansible playbook, should be possible to extend it in rulebook, per diff/patch drafted above
      • Square-bracket accessor would become, in addition to currently present dot-accessor, LHS AST and passed to Drools
      • Beyond the diff/patch drafted above, I'd plan to enable this syntax accessor on Drools side myself
      • This proposal, once I technically complete and confirm, would solve a gap in the rulebook which was identified here, to be more idiomatic in Kubernetes use-case and others.
         
        Acceptance Criteria:
         
      • introduce parser for squared accessor both ends, ansible-side and drools-integration side
      • UPDATE: it was requested to additionally support index based square braket positionally with positive and negative integer index (0-based, as Python)
      • tests

       
      Out of Scope:
       
      as otherwise not specified
       
      Additional Information:
       
      n/a

      Attachments

        Activity

          People

            mmortari@redhat.com Matteo Mortari
            mmortari@redhat.com Matteo Mortari
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: