On Monday, 4 September 2017 at 09:30:06 UTC, Suliman wrote:
Could you give an example how to make connection object if I
need access to it from several classes? Should it be global?
"""Good way""" is probably to wrap it into some ConnectionPool
(at least that's what I did).
Snipper from what I use:
final class PostgresStorage
private ConnectionPool!PostgresConection m_pool;
/// PostgresConection factory used by vibe-d connection pool
private PostgresConection spawn_connection() @safe
return new PostgresConection(someparams);
/// Client code uses this to get connection
log_debug("Trying to lock PSQL connection");
auto con = m_pool.lockConnection();
log_debug("PSQL connection locked");
m_pool = new ConnectionPool!PostgresConection(
alias PSQLConnT = PSQLConnection!(SocketT);
/// PSQL connection that is user-friendly
final class PostgresConection
private PSQLConnT m_con; // actual dpeq connection
// here goes stuff you want to expose to client code (REST
api handlers or anything else.
... some constructors and methods, for example:
m_con = new PSQLConnT(m_conn_params); // from global
parameters, taken from config
Honestly, tastes differ, It's your wheel to invent.
I use global Storage object, that can give out connections from
each connection has collection objects with methods to operate on
persistent objects. Transactions are handled by connection, other
stuff - from collections.
It's not like there is some golden standard.
If you are not writing anything concurrent, you can just make it