Open thomascothran opened 2 years ago
I have a few more patterns to add. Happy to adjust for feedback on format (and even happier to be alerted to undesirable patterns I shouldn't be recommending!).
There are a couple problems I don't yet have a good solution for, but that could be interesting.
A big one is debuggability. It would be nice to know when the rules are updating.
My current workaround is to wrap o/insert
and log or capture values. There may be a better way though.
The most recent commit makes the doc more clear on how the joins work in using O'Doyle as a query engine
Thanks i'll look them over when i have time. Just returned from my work trip so still catching up on things.
One thing it may be good to add a pattern for is visibility into rules firing. Clara has tracing listener functionality.
With O'Doyle, I've done one of two things:
then
block must call a function, and those functions are instrumented (with something like debux
), orinsert
function to add logging around when it's called, and what it's called with.Perhaps there are better ways to do this. But in my experience so far introducing people to O'Doyle, the most common difficulty (other than the paradigm shift) is understanding when and why rules are firing.
Good points. I made a ticket for improving debugging here https://github.com/oakes/odoyle-rules/issues/19
Check out the wrap-rule
fn i put in that ticket. I think it's simpler than having to rewrite your rules so they call a single function and instrumenting those functions with some extra library. If you think it's useful, maybe i could add it to odoyle. That will at least tell you when rules are firing, but not necessarily why. I'll add some ideas to that ticket once i think about it more...
17
Initializing values. How to initialize attributes to nil to avoid problems with accumulators not matching.
Loading data. Build a graph query system to pull data from local database or services.