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
auto get_connection()
{
log_debug("Trying to lock PSQL connection");
auto con = m_pool.lockConnection();
log_debug("PSQL connection locked");
return con;
}
this()
{
m_pool = new ConnectionPool!PostgresConection(
&spawn_connection, CONF.storageConfig.psql.poolsize);
}
}
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:
private this()
{
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
connection pool,
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
global.