Clojurians Log v2

Thanks @viebel for raising my question about associations here. Appreciate everyone's responses. Are there any public projects or sample code I might look at to better understand how a Clojurian deals with relational associations in practice? Many of the responses here strike me as reflections about how to do it better in the future rather than what is normal practice today.

Or maybe I'm avoiding the strict answer ... which is just work it out case-by-case because there isn't a packaged/conventional answer.

Welcome to this slack @rjs!

I think there is a more fundamental thing at play here. Rails / ORM -like solutions, although they exist, are not popular in the Clojure world. Most people like to write/use libraries and compose their solutions of these libraries. Most libraries consist of "pure" functions that receive data and return data. In the SQL world there is a library called HoneySql which allows you to construct SQL queries from Clojure data. And then you can pass that query to a database connector called clojure.java.jdbc (or next.jdbc) (which is not pure because it has to do some effect to the database). The HoneySQL library does not know about the next.jdbc library but you can compose these things together yourself. This allows for optimal flexibility but does not optimize for optimal initial setup.

But perhaps it's good to go back to your original question and get it clear what's the actual problem statement, because that might not be clear at all. Association might refer to something else than ORM/SQL.

I think in order to ask the question properly, I should try to spike something in code. That'll make the ask more concrete.

I'm just trying to envision my first steps outside of ActiveRecord. For example, the app I'm working on has lots of relations where a Task is associated with some Container via a Location. And Containers themselves are located within Phases. If I were to port my Rails-thinking directly over, I would keep some kind of map around for Containers, some kind of map for Locations, and use IDs to look up what belongs to what all the time.

I guess I would write custom functions then to look up Tasks given some Container. Again, maybe I have to spike this to understand what the real question is. I guess it's more just some anxiety about bringing the wrong mental models into a new universe.

If I would make a CRUD-like app, I would do the querying in the database (since that's where it's stored) and then this returns data (immutable) which you can then display or whatever you want. request -> handler -> sql -> data -> (html | json response)

Is using SQL in the first place somehow "off" in the Clojure world? Is everyone using Datomic, or is that the domain of some special use cases?

No not at all, SQL is often used.

Aha ok so at least I'm not in the wrong universe entirely.

But, "it's just data" 🙂

If you would like to get started with SQL, I'd start here: https://github.com/seancorfield/next-jdbc/blob/develop/doc/getting-started.md

Perhaps go through the book Web Development with Clojure: https://pragprog.com/titles/dswdcloj3/web-development-with-clojure-third-edition/ This will teach you how to build typical web apps using commonly used libraries and patterns.

There is also a "framework" which is really more like a template composed of libraries by the same author, called luminus. This is a "guestbook" example: https://github.com/luminus-framework/guestbook

Ah, looks promising. Thanks

This is a really simplified one page example of a guestbook: https://github.com/kloimhardt/babashka-scittle-guestbook For persistence it uses a file on on disk. It's a toy example really. It runs with babashka which is a scripting environment for Clojure with fast startup time and is interpreted (doesn't support all of Clojure). Conceptually it works the same as what you would do in a production app (barring things like user management, connection pooling, etc, etc, again, toy example).

@rjs and author here if you have any questions about the book 🙂

@yogthos I noticed the guestbook example hasn't been updated for a couple of years, but this is only because clojure is very stable and doesn't need updating right? ;)

more or less, I should probably update the library versions, but in terms of structure and API nothing really changed : )

I really appreciate the lack of churn in Clojure community

Amazing that a couple year-old example can still hold like that