Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for other GORM databases #43

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Conversation

wishdev
Copy link
Contributor

@wishdev wishdev commented Nov 26, 2024

Adds ability to use PostgreSQL or other GORM drivers for the database

Preserve current SQLite config options while adding a section for
DSN based connections. Currently only adding PostgreSQL, however,
any GORM driver should be available to be added.

config.yaml updated to show examples of both ways to specify
database connections.
Only need the ID/Message_ID column. The tenant_id, queue_id columns
are not index and therefore PostgreSQL will not process as a
foreign key.
Extend transaction to include select statement to allow for
FOR UPDATE/SKIP LOCKED clauses to properly dequeue rows with PostgreSQL.
Move parameter addition into proper if clause. SQLite apparantly ignores extra
parameters where other databases are more strict.
@poundifdef
Copy link
Owner

Thanks for doing this - it's taken me some time to look! I like the idea of supporting postgres+mysql using gorm. A few high-level comments:

  • I think it would be helpful to have the sqlite and postgres implementation actually implement the Queue interface, even if they are just calling Database.CreateQueue(). A couple of reasons for this:
    • The sqlite implementation uses a mutex for all writes. However, in postgres, that is not necessary, since the DB handles that
    • It would be cleaner if only the postgres module depended on gorm/postgres. As written, the database module depends on gorm/postgres but not gorm/sqlite. I think there could be a clearer separation of concerns
    • There may be cases where we want to override the default gorm implementation with custom sql

I would also prefer that the config have distinct "postgres" vs "sqlite" configs, as opposed to a generic "db" with postgres/sqlite subtypes. The reason is that if (when) we add additional database types not supported by gorm, the configuration format will be consistent.

Have other smaller stylistic comments, but that is what I'm thinking at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants