I agree but I think the best consideration is to support ORM, something like SQLAlchemy ORM. As long as we adhere to Object Relational Mapper compatible statements, many major databases could be supported! SQLAlchemy presently supports a variety of dialects including PostgreSQL, MySQL and MariaDB, SQLite, Oracle, and Microsoft SQL Server.
@ghost commented on GitHub (Apr 11, 2024):
> PostgreSQL would be a good candidate IMO
I agree but I think the best consideration is to support ORM, something like [SQLAlchemy ORM](https://docs.sqlalchemy.org/en/20/orm/index.html#sqlalchemy-orm). As long as we adhere to **Object Relational Mapper** compatible statements, many major databases could be supported! SQLAlchemy presently supports a variety of [dialects](https://docs.sqlalchemy.org/en/20/dialects/index.html#dialects) including [PostgreSQL](https://docs.sqlalchemy.org/en/20/dialects/postgresql.html), [MySQL and MariaDB](https://docs.sqlalchemy.org/en/20/dialects/mysql.html), [SQLite](https://docs.sqlalchemy.org/en/20/dialects/sqlite.html), [Oracle](https://docs.sqlalchemy.org/en/20/dialects/oracle.html), and [Microsoft SQL Server](https://docs.sqlalchemy.org/en/20/dialects/mssql.html).
@lainedfles I am in full agreement that we need a more flexible solution to data storage, but I get real nervous about ORMs, heard too many horror stories of absolutely unhinged monstrosities of queries full of JOINS being emitted by them. They can make writing the code easier, but it's usually at the cost of efficiency.
@justinh-rahb commented on GitHub (Apr 11, 2024):
@lainedfles I am in full agreement that we need a more flexible solution to data storage, but I get real nervous about ORMs, heard too many horror stories of absolutely unhinged monstrosities of queries full of JOINS being emitted by them. They can make writing the code easier, but it's usually at the cost of efficiency.
@sourabratabose commented on GitHub (Apr 14, 2024):
Any update on this one? Where is the data being handled to be stored in database? at /rag/utils.py ?
@sourabratabose commented on GitHub (Apr 14, 2024):
Any update on this one? Where is the data being handled to be stored in database? at /rag/utils.py ?
Any update on this one? Where is the data being handled to be stored in database? at /rag/utils.py ?
Not sure whether you are talking about storing the information relating to connecting to the database but I do not believe this path has any relation to that.
I am currently looking at creating relational diagram based off of the models located at backend\apps\web\models. I also believe SQLAlchemy ORM is the best option to implement this from a relational database perspective.
Would there also be considerations for something like Mongo in the future?
@sfn-git commented on GitHub (Apr 14, 2024):
> Any update on this one? Where is the data being handled to be stored in database? at /rag/utils.py ?
Not sure whether you are talking about storing the information relating to connecting to the database but I do not believe this path has any relation to that.
I am currently looking at creating relational diagram based off of the models located at backend\apps\web\models. I also believe [SQLAlchemy ORM](https://docs.sqlalchemy.org/en/20/orm/index.html#sqlalchemy-orm) is the best option to implement this from a relational database perspective.
Would there also be considerations for something like Mongo in the future?
Would there also be considerations for something like Mongo in the future?
@sfn-git
IMO, MongoDB isn't appropriate for the practical use case here as Open WebUI database is well defined and structured
@Lanhild commented on GitHub (Apr 15, 2024):
> Would there also be considerations for something like Mongo in the future?
@sfn-git
IMO, MongoDB isn't appropriate for the practical use case here as Open WebUI database is well defined and structured
The latest version works on postgresql 16, the only exception is that primary key is not set for some table, like auth table and others. Guess caused by ORM miss-configuration? Or it is intend to configure the table to has no primary key.
Test and deployed by github container images with external postgresql container instance.
@swatchion commented on GitHub (Nov 14, 2024):
The latest version works on postgresql 16, the only exception is that primary key is not set for some table, like auth table and others. Guess caused by ORM miss-configuration? Or it is intend to configure the table to has no primary key.
Test and deployed by github container images with external postgresql container instance.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @tjbck on GitHub (Apr 2, 2024).
@Lanhild commented on GitHub (Apr 8, 2024):
PostgreSQL would be a good candidate IMO
@ghost commented on GitHub (Apr 11, 2024):
I agree but I think the best consideration is to support ORM, something like SQLAlchemy ORM. As long as we adhere to Object Relational Mapper compatible statements, many major databases could be supported! SQLAlchemy presently supports a variety of dialects including PostgreSQL, MySQL and MariaDB, SQLite, Oracle, and Microsoft SQL Server.
@justinh-rahb commented on GitHub (Apr 11, 2024):
@lainedfles I am in full agreement that we need a more flexible solution to data storage, but I get real nervous about ORMs, heard too many horror stories of absolutely unhinged monstrosities of queries full of JOINS being emitted by them. They can make writing the code easier, but it's usually at the cost of efficiency.
@buroa commented on GitHub (Apr 11, 2024):
Postgres would be the best use case here.
@sourabratabose commented on GitHub (Apr 14, 2024):
Any update on this one? Where is the data being handled to be stored in database? at /rag/utils.py ?
@sfn-git commented on GitHub (Apr 14, 2024):
Not sure whether you are talking about storing the information relating to connecting to the database but I do not believe this path has any relation to that.
I am currently looking at creating relational diagram based off of the models located at backend\apps\web\models. I also believe SQLAlchemy ORM is the best option to implement this from a relational database perspective.
Would there also be considerations for something like Mongo in the future?
@Lanhild commented on GitHub (Apr 15, 2024):
IMO, MongoDB isn't appropriate for the practical use case here as Open WebUI database is well defined and structured
@swatchion commented on GitHub (Nov 14, 2024):
The latest version works on postgresql 16, the only exception is that primary key is not set for some table, like auth table and others. Guess caused by ORM miss-configuration? Or it is intend to configure the table to has no primary key.
Test and deployed by github container images with external postgresql container instance.