-
-
Notifications
You must be signed in to change notification settings - Fork 69
-
Are there plans to decouple the mongodb dependency by abstracting the database layer?
https://github.com/upper/db
or something similar could be used to facilitate?
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 3 comments 3 replies
-
Hey @c-nv-s ,
Not in the short term, not for v1 at least.
I see the point and I also think this might be a good freedom, but it would be a major refactor at this time.
That being said, I've already started regrouping the database calls into their own package. I was expecting that would come as a request.
As I'm implementing features and doing cleanup for the v1 I'd expect to have all the database calls at one place, and at that time it would be a bit easier to add an abstraction for the database.
This might be something for v2 because it will most certainly involve lots of breaking changes. But maybe I'm wrong and once everything is in one place extracting an interface and implementing different database providers would not be as hard as it would now.
Thanks for the suggestion.
Beta Was this translation helpful? Give feedback.
All reactions
-
thank you.
do you have a discord or matrix chat for the project?
Beta Was this translation helpful? Give feedback.
All reactions
-
Yes I've started a Discord last week, happy to see you there :)
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
Hey @c-nv-s
I just wanted to let you know that a Persister interface was created and PostgreSQL support added in the last release v1.2.0.
This could also open the door to other database engine.
It's still "document" based because it's using the JSONB feature of PostgreSQL, but I think the results is very clean.
Up next is creation of indexes to optimize queries.
Let me know if that works for you.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1 -
🎉 1
-
awesome dstpierre, thanks so much for this i'll test it out when I get an opportunity.
just a note for the docker-compose files: it would make it really flexible if we could provide a DSN string for the database connections via an env variable. for example take a look at
https://github.com/kos-v/dsnparser
https://github.com/xo/dburl
this would allow users to better specify where the database is.
Beta Was this translation helpful? Give feedback.
All reactions
-
Yep, the env is named DATABASE_URL - all required variables can be found in the .demo.env
It's more of a connection string than a DSN. I think it could be nice to use URL-like for specifying database connection strings option, maybe introducing another env variable like DATABASE_CONN_STRING for provider's specific connection string format. And leave the DATABASE_URL for URL-like database DSN.
I'll create an issue for this. Thanks
Beta Was this translation helpful? Give feedback.