Support other database backends #167
Labels
No Label
Roadmap
V
bug
docs
duplicate
enhancement
good first issue
help wanted
idea
invalid
question
wontfix
Idea
Roadmap
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Depends on
#283 Fully database-agnostic code
vieter-v/vieter
Reference: vieter-v/vieter#167
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
Vlib has support for sqlite, postgresql & mysql/mariadb. If we could re-write the code to choose which database type to use, the ORM would allow us to choose one over the other.
The ORM is currently not complete enough to allow for this.
I think this could be accomplished by not using the ORM syntax at all. Instead, all database operations could rely on the
orm.Connection
interface. Then the type of the database connection could be justorm.Connection
, allowing multiple database backends!Of course, this still leaves the problem of migrations. We'd have to write migrations for every database backend that we wish to support.
this PR could make this simpler, as it would allow us to use a generic
orm.Connection
object for ORM operations, leaving only the problem of custom migrations.The above PR has not been merged in the V 0.3.2 release, so we'll most likely have to wait until V 0.3.3 to fully implement this. However, we can already pave the way by implementing #283.
The PR didn't make it into V 0.3.3 🤷♂️