A more functional API

[yannvanhalewyn]

I recently discovered this library and I really like it!

I would like to be able to enjoy the features of this library but with a more functional API. The macro API makes it impossible for me to integrate it in my current projects. There are three points that would make this library more suitable for modern clojure. Ordered by importance.

1. Allow reading schema at runtime

As is, and as I understand it, you can only use this library with a fixed database at compile time. There are many use cases where you would want to be able to do this at runtime. Most of which are my use cases 😉

• When compiling on a build server that is not connected to a database
• When part of a Component / Integrant / Mount setup where all side-effects are managed together (you would only get a database connection when the system starts up). It would also be nice to re-fetch the schema after running a migration.
• When connecting to multiple databases with different schemas.

All three of those scenarios are simultaneously present in both my current work project and hobby project.

2. Have the schema be a first class citizen

As mentioned in the previous point, using this with multiple databases would merge the schemas and be prone to conflicts and malformed queries. I would suggest this approach in order to not break compatibility:

(specql.core/read-tables db ["users" :user/users])
;; => {:user/users {:name "users" :type :table :columns {...}}}

;; The consumer could keep in his system or wherever he wants
;; Then when we query:

(def db {:datasource ...
         :specql.core/schema {...}})
(specql.core/fetch db :users/users {:user/id 1})

;; In fetch we either use the provided schema, or the global registry if none

This way, it doesn't matter how many or when databases are used. The data-circuit is clean and closed, no global state. I think this is a valuable improvement and I don't think this would be an expensive effort, it looks to be an issue of re-arranging existing code. I might be wrong of course.

Is this something you would be open to discuss, pick up, or accept a contribution for?

[tatut]

Good suggestions.

I've been meaning to do a specql2 at some point that fixes schema and a bunch of other issues. I'm currently not working on it, though.

I would suggest a fork so you can start from a clean slate API-wise.

[yannvanhalewyn]

@tatut Thanks for the reply. I will think about a fork or other solution for now then.