Clojurians Log v2

Thank you @mauricio.szabo for participating to this discussion

It seems that with bee-record you tried to port the good parts of ActiveRecord to Clojure. Is that correct?

@viebel I totally agree that there's a problem (but unsure of the best solution). The problem can be stated as: There's data in your database (call it DB) and there's the language data structures (Clojure or Ruby, no difference, call it LANG) which everybody knows and loves to use. How do you create a two-way connection between the two data models? Fetch data from DB, converts to LANG. Change some data in LANG, magically end up in DB. On the surface, this seems straightforward. But in practice, it never is. Sometimes you need just the "person". But other times you need the "person" with the list of "orders" that they've placed in the last 30 days. Joining data, filtering data, removing data, using caches like Memcache, etc, makes the process of constructing the LANG data complex.

And that's just in terms of correctness. There's also general performance and/or per-database specific-features (MySQL vs Postgres, for example) that you might want to use.

@cgrand How does this topic relate to your "map fatigue" idea?

Spot on: it's about relational/hierarchical mismatch which to me has two factors: • a border between db and lang • Lang not being relational

The most common pain to me is that when you need to retrieve an additional piece of data like an extra field you have to modify the query and the shaping code (map juggling).

These days I'm thinking about templating-as-querying where by templating I mean the process of turning relational data in hierarchical data – with more control on the output shape than what pull queries allow.

> you need to retrieve an additional piece of data like an extra field you have to modify the query and the shaping code this problem is solved for me by honeysql completely

And for me this problem is solved by graphql

and for you @cgrand?

If you walk the resulting DS you’ve lost 😄 Imagine the goal is to display (Flutter widgets, DOM, HTML, JSON, whatever) a list of physicians and for each physician a list of free slots for appointements. I’d like to infer the query from the “templating” code (even if shaping clj maps into JSON is seldomly seen as templating). The closer one can get to this feeling is by using datomic entities (the lazy associative thingies returned by d/entity).

For me the problem is partially solved by multiple solutions, but specially by HoneySQL and Pathom - both libraries that I'm using at BeeRecord

As for the BeeRecord, at the beginning yes, I was trying to port the good parts of SQL to Clojure. But then things became really complex and I wasn't sure that this code was correct or desirable anymore. So I focused on the second idea that I had - the walk namespace - where I wanted to focus on generating the right (INNER) JOINs for a specific data.

Using the example of @raspasov, if you want the list of "orders" that a "person" placed in the last 30 days, you could query for a person, then filter the orders. The "orders" table can be a direct join from "person", or not - it can be, for example, behind a join table for some reason. If we translate this to HoneySQL, you have a :select, a :where, and lots of noise. The idea of BeeRecord/walker is to remove the noise: (to-honey {:select [:person/name :order/number] :where [:> :order/placed-at a-month-ago]})

This will generate one query. And that's the issue (because if the user placed multiple orders, the :person/name will be returned multiple times). Then Pathom3 got stable, and I'm currently working on making the less number of queries possible to retrieve the data. So for example, this is the API for bee-record.sql for now:

(query [:person/name {'(:person/order {:where [:> :order/placed-at a-month-ago]})
                       [:order/number]}])

Now for the issues I'm having: first, I'm not really happy with the :person/order subkey - I want it to be more configurable, so I'm studying alternatives. The most problematic issue is that they have to be unique over the whole query because they will be queried by batches. The second problem is that the current implementation expects the :person/order key is in the format of FROM/TO, and I want to remove "conventions" and allow the user to define what he wants the association data to be named

What I have in mind is something like:

(xx/deft last-30-days-orders [user-id]
  [:div
   [:div (:user/first-name user-id) "'s orders:"]
   [:ul
    (xx/for [#order {:owner user-id
                     :placed-at t
                     :_/as order}
             (< thirty-days-ago t)]
      :sorted-by (> t)
      [:li (:order/number order)])]])