Clojurians Log v2

@caleb.macdonaldblack interesting you say that, because in my view pathom does follow EAV, in the sense that each map in the system is the E, each attributes is A, and V for hte value, when navigating relationships, its about changing the E, getting some new A's and V's

but maybe what makes it different is that, since its all attribute based, the context of E is always dependent of the starting A's of it, and each E reach must depend only on those A's initially available (which means it doesn't allow for extra contextual data is not part of the A's, like knowing which was the parent, because I think this has implications that would make things too complicated, instead, all context must be provided in the form of attributes at that entity)

(of course, initial attributes + your resolvers)

I’ve also wondered the same thing. https://clojurians.slack.com/archives/C87NB2CFN/p1630459977019600 I’m fascinated with Pathom, Datoms/Datalog, namespacing and lisp. And I’ve been thinking about it so much over the past couple of years. I’m convinced that programming in this way is superior to typically approaches. But I’m also baffled how under-utilised these concepts are. Also I’m pretty sure that these concepts aren’t new, but actually fairly old. So if this is the case, then why has software engineering seemly left these ideas behind? I was recently inspired by @joel380’s message a few days ago https://clojurians.slack.com/archives/C87NB2CFN/p1680112245568369 regarding O’Doyles rules. I’m yet to play around with it, but it feels similar to how Pathom works. I’m starting to think Pathom is actually a rules engine. So anyway, I started to look into O’Doyles rules and watched this talk by its creator: https://www.youtube.com/watch?app=desktop&t=38m37s&v=27KuJU8r4-U The full talk is great, but he does try and answer the question as to why these approaches are so hard to find in modern programming and he believes it might just be “lost wisdom”.

So I guess to answer your question to best of my knowledge. I think Pathom is really just a rules engine. And existing rules engines are probably the closest thing to Pathom outside of Clojure. Apart from rules engines, there doesn’t seem to be any popular tools similar to Pathom anywhere else.

Thanks @caleb.macdonaldblack. I'm not convinced Pathom is a rules engine. As a user of Clara for many years it feels quite different... Actually I have much less experience with Pathom and Datomic than Clara, and none professionally. But I am a fan of the attribute first approach to data modelling and I've seen the problem of simply wiring microservice logic to other microservice REST endpoints, which is lots of custom code and coupling. So I'm looking something like Pathom in other projects. I feel like GraphQL is the dominant player in this space, but also quite different in ways I don't think I like that much. Netflix Falcor is older and less popular but perhaps more similar? Also if anyone knows whether Pathom can be used as a pure JS (or Java!) library that would be interesting too 🙂

Perhaps I am thinking particularly about "Pathom connect" rather than Pathom, as in my researches I've tended to conflate the two. Apologies if so 😊

No worries. I’ve never actually used a rule engine so it’s very possible I’m mislabelling Pathom as one. Some of the reasons why it feels like one (in my limited experience), is its ability to implicitly handle logic flow. For example I might ask a Pathom network for a user/type attribute and a couple of resolvers will exist that can derive that attribute when certain inputs exists. For example a resolver could require an employee/id to provide the user/type attribute with a value of user/employee and another resolver could deal with the respective resolver to handle a user/customer type. Then after executing that query, Pathom would execute whichever resolver it has the data for. Another example I’ve actually run into is trying to determine whether or not I should hide a particular entity from a list. So I would have a generic attribute for hiddenness, which is derived from more specifically named attributes. user-hidden admin-hidden or even the absences of required attributes such as title. There are many different “rules?” which could be implemented in a Pathom network to determine what a derived value might be. However, with all that said. Pathom is still very useful for more simple problems like mapping and selecting data between systems. I’ve found it very useful for mapping legacy data-structures to newer ones.

I’m very excited to play around with O’Doyle & Clara as I’ve only very recently discovered them. @apbleonard, in your experience, and the examples I’ve described, would you suggest Clara or maybe others to be well suited for these kinds problems I’m trying to solve? Do you have any other thoughts even cautionary advice for me?

@caleb.macdonaldblack - I think it’s fair to say pathom is a specialized rule engine, or akin to prolog in a sense. It’s figuring out how to derive new facts from existing facts. A forward chaining rule system (that’s most of ’em) wouldn’t know up front what can be derived. It just fires valid rules and those in turn produce more facts that can again trigger subsequent rules. Pathom can actually figure out up-front what can be derived, this makes it relate a bit more to prolog (or core.logic). On a previous project, we used Java coupled with Drools (another rule engine). Some rules would state what fact was needed, and then other rules would fetch the actual data. This works well enough, but I’d like to be less explicit and make that part of the “engine”. I think the trade-off is that pathom is concise and less flexible (and can “look ahead”), whereas rules are more verbose, and more flexible (but can’t “look ahead”).

That’s very interesting. Do you think a rules engine could “look ahead” like Pathom does? Or is there something that makes this challenging or impossible?

I’m envisioning an ideal system that can “look-ahead” to derive data as needed (like Pathom) but operates on EAV data instead of maps. I’ve found Pathom’s map/entity based approach to be limiting when modeling relationships. Pathom works perfectly with flat maps but struggles to deal with relationships (nesting).

If you use backward chaining then you can “look ahead”. Pathom and Prolog can do this because the left-hand-side (or pathom’s input) and right-hand-side (pathom’s output) are clearly specified. Look ahead is problematic with most rules engines that rely on forward chaining only, and that’s because the RHS doesn’t have a spec, but can be arbitrary code --- that will often insert a new fact into the session to trigger more rules.

Yeah, the data modeling is difficult. I find the EAV representation intriguing, but understand it may struggle with many-to-many relationships… I haven’t done much with it, but it definitely seems worth exploring. @caleb.macdonaldblack

I’m guessing, @caleb.macdonaldblack when you are talking about EAVs you are thinking about the triplet format, or possibly the datalog query format (instead of EQL)? It seems like no matter what you do there’s always a “data impedance mismatch” to some degree… But I’d also be curious how that kind of implementation would compare (maps->triplets, eql->datalog).