This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-12
Channels
- # adventofcode (6)
- # beginners (148)
- # boot (5)
- # calva (1)
- # cider (10)
- # cljdoc (10)
- # cljs-dev (8)
- # cljsrn (10)
- # clojure (180)
- # clojure-dev (24)
- # clojure-europe (2)
- # clojure-finland (1)
- # clojure-italy (32)
- # clojure-losangeles (1)
- # clojure-nl (40)
- # clojure-spec (10)
- # clojure-uk (44)
- # clojured (4)
- # clojurescript (88)
- # community-development (33)
- # core-async (7)
- # cursive (19)
- # datomic (98)
- # duct (3)
- # events (1)
- # figwheel-main (10)
- # fulcro (62)
- # leiningen (23)
- # luminus (18)
- # off-topic (19)
- # pedestal (6)
- # re-frame (46)
- # reagent (21)
- # ring (17)
- # ring-swagger (3)
- # shadow-cljs (94)
- # slack-help (9)
- # spacemacs (14)
- # sql (1)
- # testing (4)
- # tools-deps (14)
is it ok to have two different interceptors
about (in memory) database, one for a "table" X and other for "table" Y?
@leandrotk100, I’ll hesitantly say yes but I don’t know your use case
I have a in-memory database:
{:users [...]
:connections [...]}
I implemented a simple CRUD to the users, and I used a db-interceptor
specific for the users
Now I was thinking about the connections
and (maybe) another db-interceptor
, something like db-connection-interceptor
In general, I implement an interceptor to create/get a connection and make it available on the context for other interceptors