3 ms·

We're going to add support for more DBs (e.g. Postgres and MySql) in the next release, I did a lot of work on the underlying libraries to make that possible. H

We're going to add support for more DBs (e.g. Postgres and MySql) in the next release, I did a lot of work on the underlying libraries to make that possible. However, mapping the tables/field names is not planned. I think it's a can of worms that I don't want to open: How do you populate the fields you don't know about but are mandatory when creating a new user/group? You could go the way of setting up a middleman service that listens to the binary queries to (e.g.) postgres and "tranlates" them by substituting the field names, but that seems complicated.

dingleberry420 4y ago
First of all, read only functionality would be good enough for me. Especially if it can read from a database view which could be backed by my other tables. I often deal with user databases managed by custom software which we also want to let be consumed by something that speaks ldap, and it would be great not having to synchronize stuff, instead having a single source of truth. So perhaps if it can read from a view with a schema defined by you, that would work? And perhaps for inserting/updating user/groups, you could require the database have a specific stored procedure present? Initially I was thinking about allowing templated queries, where the administrator can specify the field names. For inserts, the database will just have to provide sensible defaults or let the insert go through a stored procedure that provides such. But doing everything using views & stored procedures might be simpler?
- nitnelave 4y ago
  I'm not a DB expert so I don't know much about stored procedures. Given that I'm trying to stay compatible with all of sqlite/mysql/postgresql, it might be difficult to rely on stored procedures horizontally. A read-only view would be possible, the schema is quite simple. If you want, you could create an issue for that! Keep in mind that the DB schema is more of an implementation detail than a public API, so I'm not going to consider an (automatically-migrated) schema change as a breaking change.

dingleberry420 4y ago

First of all, read only functionality would be good enough for me. Especially if it can read from a database view which could be backed by my other tables. I often deal with user databases managed by custom software which we also want to let be consumed by something that speaks ldap, and it would be great not having to synchronize stuff, instead having a single source of truth. So perhaps if it can read from a view with a schema defined by you, that would work? And perhaps for inserting/updating user/groups, you could require the database have a specific stored procedure present? Initially I was thinking about allowing templated queries, where the administrator can specify the field names. For inserts, the database will just have to provide sensible defaults or let the insert go through a stored procedure that provides such. But doing everything using views & stored procedures might be simpler?

nitnelave 4y ago
I'm not a DB expert so I don't know much about stored procedures. Given that I'm trying to stay compatible with all of sqlite/mysql/postgresql, it might be difficult to rely on stored procedures horizontally. A read-only view would be possible, the schema is quite simple. If you want, you could create an issue for that! Keep in mind that the DB schema is more of an implementation detail than a public API, so I'm not going to consider an (automatically-migrated) schema change as a breaking change.