Clojurians Log v2

hey guys, I some help to understand component spirit.

Let say i have a component do mange my database connection, and from that connection I retrive a database to perform operation.

What do you understand so far / what do you feel you need more insight on?

if i lose the connection, that is mean i lost the databse also?

Actually i want o use component to manage my database connexion

and think about the best way to do that

I am using monger

I'll give an example of how we use Component at work in that area: we have a Configuration Component -- start loads the configuration from a file etc, stop basically does nothing; we have a Database Component -- it depends on Configuration (for database host/user/password etc), start builds a connection pool (a datasource), stop shuts it down.

I don't know how Monger handles reconnecting but I think the underlying Java driver for MongoDB takes care of that, so whatever Monger does to build that "object" should be your start function, and then assoc it into the component.

I see people having component for connection and for database. And i really don’t get the point about doing that. since to me the database retrive from a connection is tight that connection.

Then you'll pass the Database Component around in your code (say as a database argument to functions) and then get the MongoDB connection pool from that any time you need to do a DB operation: (:mongodb database) for example.

The key benefit of component is to standardize the start/stop lifecycle aspect of "resource"-like things and encapsulate this "managed state" inside the component.

And to automate the dependency management stuff (Database depends-on Configuration etc).

I would always use a connection pool that will manage reconnections. It'll be a mutable Java object (pretty much by definition). Passing it around inside a Component lets you manage start/stop which is especially useful in the REPL and also in tests.

We actually have several connection pools in our Database Component. For our main DB, for our billing DB, for our messaging DB. Back when we used MongoDB as well (via CongoMongo), it used to contain our various MongoDB connection pools as well (again a main :mongo and a :mongo-log connection pool).

Does that help?

yeah that helps a lot

I'm not sure what you mean by "the database retrive from a connection is tight that connection"

really

On monger i get a connection and from that connection a take a database to perfom action on.

Ah, yeah, Mongo has kinda weird terminology.

so i think i should only have connection of monger and retrieve from it the database when i need to do something

The "connection" is a connection pool manager I think, right?

yeah

And, yeah, you would keep that in your Component and wherever you do a Monger operation, you get that from your Component and then get the DB handle for the operation.

that is the way i think it should be

check this link

https://www.reddit.com/r/Clojure/comments/3ymnnh/clojure_component_question/

Assuming you have an application Component that has the configuration and database Components in it, you'd do stuff like

(monger/some-op (-> application :database :connection (monger/get-db :my-db)) ...)

connection is a component and database is another component

I wouldn't do that.

hanhaaaaannnnnnnn

because let say i took a database from a pool and that pool die for some reason. What happen with the database took from it?

Components are really for global things that have a specific start/stop lifecycle -- creating a connection pool, for example -- but getting a DB handle is something short-lived, just for the operation you are performing. It doesn't belong in a Component.

Your explanation make sense a lot to me

thank you very much for taking time to answer me

Happy to help -- we're heavy users of Component at work.

I am thinking about having a component for database which will handle the connection pool actually

and have a protocol to define functions for my database

I hope i will reach the point thta i will really be confortable with components

Unless your database interactions are fairly small/well-defined, I wouldn't bother with a protocol for them. Unless you really are going to have multiple implementations?

no no

just one database

but the interaction are fairly small

Protocols only really make sense when you have multiple implementations (for different JVM-level types).

actually i am build an api just to learn clojure dev good practices

i see

This is still good advice about Clojure types https://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/

thank you very much for the link 🙂