pedestal

2019-02-12T12:09:11.010300Z

is it ok to have two different interceptors about (in memory) database, one for a "table" X and other for "table" Y?

2019-02-12T14:15:34.012100Z

@leandrotk100, I’ll hesitantly say yes but I don’t know your use case

2019-02-12T15:08:54.014500Z

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

2019-02-12T15:10:51.015500Z

In general, I implement an interceptor to create/get a connection and make it available on the context for other interceptors

2019-02-12T15:11:34.016300Z

I may also implement an interceptor which fetches an entity from the db and makes it available on the context/request as well.

2019-02-12T15:12:11.017Z

In general, I think it’s good practice to limit handlers to response formatting and push data retrieval to interceptors