Fork me on GitHub
#component
<
2017-07-04
>
devth16:07:05

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?

devth16:07:15

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

potetm16:07:23

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

noisesmith16:07:39

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

potetm16:07:06

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

noisesmith16:07:08

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

potetm16:07:36

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

devth16:07:52

ok. i could probably reset the entire system

potetm16:07:59

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

potetm17:07:26

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).

devth17:07:53

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

devth17:07:58

probably cleanest to restart the entire system

potetm17:07:49

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

potetm17:07:24

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

potetm17:07:44

And you can look up connections via URI at will.

potetm17:07:57

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

devth17:07:04

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

devth17:07:10

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

noisesmith17:07:02

you can restart a system without restarting either jvm or repl

devth17:07:14

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

devth17:07:26

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

noisesmith17:07:26

yeah, you can easily do that with the whole system

potetm17:07:27

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

noisesmith17:07:30

just stop it then start it

devth17:07:51

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

potetm17:07:04

Yeah don't store the conn in a component.

potetm17:07:10

Is what I'm saying.

devth17:07:18

oh really

potetm17:07:41

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

devth17:07:59

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

potetm17:07:11

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

potetm17:07:28

Yeah that would work perfect.

potetm17:07:56

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

potetm17:07:09

But no need to release connections.

devth17:07:48

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

potetm17:07:02

Conceptually the URI is a dispatch value to a connection.

devth17:07:04

i only have 1 db-uri

devth17:07:08

(currently)

hiredman17:07:30

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

potetm17:07:00

And those connections are already managed for you.

potetm17:07:20

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

potetm17:07:21

(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.)

devth17:07:35

good to know. thanks!