Interesting questions raised on Twitter by a Ruby on Rails guru about how do we deal with associations in Data-Oriented Programming. https://twitter.com/rjs/status/1472594929943732224

@viebel I would respond, but he limited to only the guy who he referred to in the tweet ;)

So there's even no point in asking bbatsov as he can't reply to that question.

What I would have responded: use SQL, not some ORM framework. Use HoneySQL.

It is of course a trade-off but that's my trade-off

I think pathom provides a good example for how to deal with associations in DOP

if you go with a datalog database it becomes even easier in that respect, maybe you should mention datomic etc in the context of "DOP"-style database, if you haven't done that already (I bet you have!)

@borkdude HoneySQL doesn't really address associations. Here is how ActiveRecord deals with association https://guides.rubyonrails.org/association_basics.html. @mauricio.szabo implemented something in the spirit of ActiveRecord in Clojure with https://github.com/mauricioszabo/bee-record.

The most interesting question to me is not: How to implement ActiveRecord associations in Clojure or in DOP

yeah, I know ActiveRecord and I'm just not a fan of this automagical behavior, I'll just write my own SQL thank you

That's exactly the interesting question: why in the Clojure ecosystem we are not fans of the kind of easiness ActiveRecord proposes. And don't answer me "simple is not easy" 😉

that's exactly the problem of rails

What exactly?

for some subset of web-apps, it's the exact right fit, but when you need something slightly different you start fighting against its "complected" nature

</rant>

I see what you mean. But let's focus the discussion on the topics of "associations"

associations don't mean necessarily ORM

yeah, let's start with a problem statement, this is the right place to start instead

OK. Let me try

but as this Rails / Basecamp guy has locked the conversation, I'm not really interested in the discussion, since it's his question, not mine.

But now I have a question

I am not asking in his name

I am asking on my name

That's how I'd frame my question: Is the problem addressed by https://github.com/mauricioszabo/bee-record is important in the Clojure ecosystem?

I see bee-record as a way of helping to construct SQL queries and executing them. It's a library on top of HugSQL. You still get to use data and inspect the SQL query that comes out of it. I haven't used this library, but yes, I think this would be a nice DOP-ish approach to how to do associations.

I don't agree necessarily with the premise of this library that SQL is hard, that's quite subjective

Have you read about pathom? I think it provides a good solution to the “association problem”

@smith.adriane any examples of pathom + sql?

@borkdude I am really curious why bee-record is not more popular

@viebel I'm not sure, but I probably wouldn't reach for it myself since I just want to write my own functions on top of hugsql

I don't have any sql examples off the top of my head, but one of the benefits of pathom is that “what” is separated from “how” so relations can be defined logically regardless of whether sql or something else is used under the hood. If you wanted to create a relation across databases, it's the same stuff.

similar to graphql maybe

what I'm always concerned about with these kinds of solutions is: how many queries will it do to fetch something which I can do in 1 query where I still have all control

but perhaps for many apps this isn't a concern and they want an off the shelf "quick" solution. I think Rails plays more in that area

Maybe

one important difference that pathom shares with data log is that the queries are data. I guess that's where something like honey-sql can help.

Hi folks, entering the discussion

So, the current implementation of BeeRecord does use Pathom to make things easier: https://gitlab.com/mauricioszabo/bee-record

The idea that I had was: supposing that I have tables (entities). I want to represent how entities "join" each other in a less magical way. So I wrote the "mapping" of these entities as HoneySQL ASTs, so for example, if I do have person that maps to a table called people and role that maps to people_roles, I simply will write a mapping like

{:person :people :role :people_roles :joins [:= :people.id :people_roles.person_id]}

And then if I want to query for people and their roles, I could just write a "partial HoneySQL" query like {:select [:person/name :role/name]} For associations, I'm quite unsure how to do it. I'm currently using Pathom to graph the queries, but I'm not happy with the "query format" really

As for the original question: > why in the Clojure ecosystem we are not fans of the kind of easiness ActiveRecord proposes ActiveRecord is wonderful if you stay on the happy path. It's close to impossible to know when a query will issue, and how many queries it'll issue. There are also a lot of edge-cases, things that changed behavior between versions, API renaming fiascos, change of behavior without changing the operation name, sanitization issues (`.where(foo: 'bar')` sanitizes the query; .select(:foo) don't), inconsistencies at the API, lots of things silently fail, and gosh, how slow it is... in fact, I wrote about it here: https://mauricio.szabo.link/blog/2019/07/20/rails-activerecord-the-bad-and-the-ugly/

What I don't really like of ActiveRecord (or most ORMs, really) is that while they are a shortcut for a quick prototype/first version of a code, they poison the codebase in way that's close to impossible to replace.