[SR-Users] RFC: db_redisusrloc module - review and how to deal with

[Daniel-Constantin Mierla]

Hello,

for fairness and a more complete picture, I should have mentioned that I
am somehow the first that broke into module specific backend with topos
and topos_redis. In that case, I was also guided by the goals of
squeezing what ever can be exploited in terms of performances from Redis
backend, given that topology hiding with stripping/adding back headers
for all SIP traffic needs be be (ideally) very fast.

The topos module had DB API support and can be used with mysql,
postgres, etc ... topos_redis was added as an alternative to use
directly a Redis server. However, topis_redis is not on top of DB API,
therefore a name not related to it at all.

Cheers,
Daniel


On 21.02.18 10:48, Alex Balashov wrote:
> Hi,
>
> I have not dived into the technical specifics deeply or examined the
> innards of db_redis, so this is really shooting from the hip: 
>
> I can appreciate the very legitimate dilemma here. However, in general I
> would advocate for keeping all DB connectors generic.
>
> Although I understand that there are some punishing generalisations and
> contortions required to shoehorn particular modules' schematic
> requirements into the more general DB API, there is a lot of value in
> the highly consistent database agnosticism afforded by doing this. This
> is similar to the trade-offs involved in using ORMs a lot of the time.
> As things currently stand, it is possible to use any db_* backend with
> Kamailio in a highly interchangeable way, and not many DB-backed systems
> can truly deliver on that promise. Kamailio shines as a rare exception.
>
> The other problem is that the leaky / inconsistent abstractions involved
> in more Byzantine DB module choices will be confusing to users, most of
> whom are not software engineers presumably and will not easily
> understand the difference between a module-specific DB connector and a
> generic one. It will also lead to some needless duplication of effort
> and possibly lopsided support for one or the other pathway to the
> database in cases where a module has both generic and module-specific
> connector support.
>
> Finally, although I understand that third parties contributing modules
> are charged with maintaining them, it seems to be a practical effect
> that you (Daniel) and others are dragged into maintaining orphaned or
> semi-orphaned modules, or the "plumbing" dependencies that they generate
> within common code. The project already has a bewildering array of
> modules, all moving at different speeds, having different levels of
> sophistication and so forth. Now, I know that I have always taken a more
> conservative position on matters of curation of third-party
> contributions relative to the implicit maintenance burden, and we may
> differ on that, but I think pouring more fuel on that fire by splicing
> in multiple levels of DB abstraction for some modules will create
> unnecessary maintenance headaches without the corresponding pay-off. 
>
> Whether the database is traditional relational or schemaless, I don't
> think it's unreasonable to ask that any DB-backed module adhere to the
> common DB API and use those mechanisms to interact with the DB. It just
> leads to more consistent, maintainable code and more predictable
> outcomes, while providing a level of flexibility people have come to
> expect with the RDBM-backed modules.
>
> -- Alex
>

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com