Clojurians Log v2

can I stop/start a single component that's part of a larger system and expect it to propagate to the other components that depend on it?

seems that is not the case. not sure if i need to re-construct the entire system

@devth No, that's not a supported use case.

each part of the system is meant to be immutable, which means restarting foo means restarting transitively everything that uses foo

Operations happen over the entire system. You can manually traverse the system with update-system if you wish.

(but maybe you could get away with not restarting the things foo uses - maybe hack?)

You can also look at how things in component are implemented (see tools.namespace), and traverse the graph yourself.

ok. i could probably reset the entire system

But know that it's conceptually much more difficult to manage than just restarting the entire system.

The only downside I see there is speed. If for some reason cycling some particular component is slow, it might need to be avoided. But I have yet to have a system restart that takes longer than a second (and I have some pretty big systems).

cool. in this case i need to reset a released Datomic connection. other components in the system are the web server and an elasticsearch connection

probably cleanest to restart the entire system

You know what? I don't even release my datomic conns on system restart. I forgot that fn even existed.

Datomic is kind of a special animal IMO. It's inherently tied to the lifecycle of the VM (via agents).

And you can look up connections via URI at will.

So there's not a lot of advantage for managing connection passing yourself.

the problem is sometimes during dev i need to recreate the database, which releases the connection

i want to do this without restarting my entire jvm/repl

you can restart a system without restarting either jvm or repl

right - that's what i'm aiming to do 🙂

but my first stab was to think about only restarting the datomic sub-component

yeah, you can easily do that with the whole system

Manually call (d/delete-database uri) (d/create-database uri)?

just stop it then start it

@potetm yep, but the connection stored in the db component will be released when i do that

Yeah don't store the conn in a component.

Is what I'm saying.

oh really

I find that relationship awkward, especially considering datomic has its own resources it manages anyways.

you store the db-uri in the component and d/connect anywhere you need a conn?

I do have a datomic component in my system, but I have multiple databases, and must dispatch on a value other than the URI.

Yeah that would work perfect.

Or you create a component that wraps anything that uses a URI if you want to make the URI opaque.

But no need to release connections.

maybe i'll store a thunk that creates a conn in the db component

Conceptually the URI is a dispatch value to a connection.

i only have 1 db-uri

(currently)

you can implement IFn for a defrecord so your component could be the thunk

oh cool

And those connections are already managed for you.

So no need to take over something that Datomic has already agreed to do correctly. Just pass the dispatch value.

right

(I fought this battle for a while. I really wanted to do a full restart via d/shutdown. After a while, I found that with datomic and core.async it's better to let them live tied to the VM and not try to manage them via component.)

good to know. thanks!