Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect Event Triggering #24

Open
MafcoCinco opened this issue Feb 7, 2020 · 1 comment
Open

Incorrect Event Triggering #24

MafcoCinco opened this issue Feb 7, 2020 · 1 comment
Labels
bug Something isn't working

Comments

@MafcoCinco
Copy link
Collaborator

In certain dependency configurations, events are not triggered properly. The below example is a simple schema that replicates the bug:

(def schema {:model [[:a {:id :a}]
                     [:b {:id :b}]
                     [:c {:id :c}]
                     [:d {:id :d}]]
​
             :events [{:inputs  [:a :b]
                       :outputs [:c]
                       :handler (fn [_ {:keys [a b]} _] {:c (+ a b)})}
                      {:inputs  [:a :c]
                       :outputs [:d]
                       :handler (fn [_ {:keys [a c] :or {c 0}} _] {:d (+ a c)})}]})

When the above schema is initialized and a transaction is executed with the following input:

(-> (domino/initialize schema) 
    (domino/transact [[[:a] 1] [[:b] 1]]))

there will be a NullPointerExecption. Furthermore, even if the second event handler is implemented to account for the fact that it could be called with a nil value of c, the correct output is never actually obtained as the handler is not invoked a second time when the db is updated with a new value for c (from the first event).

This highlights 3 issues:

  • The documentation should be updated, provided it does not already contain this information, to indicate that event handlers can be called with partial input. Users should not assume that all data is populated and they may receive some nil values

  • The event processing code should be fixed such that the handler for the second event is invoked a second time when a new value of c is placed into the db as a result of executing the first event

  • nil values should be stripped out of the input to event handlers in order to keep destructuring working correctly. The above schema causes a NullPointerException even though it contains an :or {c 0}. The reason for this is the input to the handler contains the key :c which has a value of nil. As such, the :or ... is not evaluated during destructuring and c retains a value of nil.

@yogthos yogthos added bug Something isn't working help wanted Extra attention is needed labels Feb 29, 2020
@yogthos
Copy link
Collaborator

yogthos commented Mar 5, 2020

@SVMBrown fixed the issue by allowing the events to be executed multiple times. This will impact cases where event functions aren't pure, but that's not a supported or encourage use case at the moment.
221fad4

@yogthos yogthos removed the help wanted Extra attention is needed label Mar 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants