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

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