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 using database/sql driver with functioning pgx listener #352

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Commits on May 13, 2024

  1. Fully functional database/sql driver

    Here, implement the rest of driver functionality on `riverdatabasesql`,
    the existing driver for Go's built-in `database/sql` package. Previously
    it only supported a minimal interface allowing it to run migrations, but
    nothing more sophisticated like inserting jobs.
    
    The benefit of a fully functional driver is that it will allow River to
    be integrated with with other Go database packages that aren't built
    around Pgx like Bun (requested in #302) and GORM (requested in #58).
    I'll need to write up some documentation, but this change should make
    both of those integrations possible immediately.
    
    It also lays the groundwork for future non-Postgres drivers. It's going
    to be a little more still, but I want to take a stab at SQLite, and this
    change will get us a lot of the way there.
    
    There's no way with `database/sql` to support listen/notify, so here we
    introduce the idea of a poll only driver. River's client checks whether
    a driver can support listen/notify on initialization, and if not, it
    enters poll only mode the same way as if configured with `PollOnly`.
    
    An intuitive idiosyncrasy of this set up is that even when using the
    `database/sql` driver bundled here, regardless of whether they're
    working with Bun, GORM, or whatever,  users will generally still be
    using Pgx under the hood since it's the only maintained and fully
    functional Postgres driver in the Go ecosystem. With that said, the
    driver still has to bundle in `lib/pq` for various constructs like
    `pq.Array` because we're using sqlc, and sqlc's `database/sql` driver
    always uses `lib/pq`. I tried to find a way around this, but came out
    fairly convinced that there is none. To rid ourselves of `lib/pq`
    completely we'd need sqlc to ship an alternative Pgx driver that used
    Pgx internally, but exposed a `database/sql` interface using `*sql.Tx`
    instead of `pgx.Tx`.
    brandur committed May 13, 2024
    Configuration menu
    Copy the full SHA
    755295f View commit details
    Browse the repository at this point in the history

Commits on May 23, 2024

  1. demonstrate alternative constructor w/ listener support

    Add a `NewWithListener` constructor to `riverdatabasesql` that allows
    the `database/sql` driver to be used with a functioning listener
    implementation. Also add a `NewListener` constructor to the `riverpgxv5`
    driver to allow creating a listener with a raw pgx pool.
    
    These can be combined to allow full listener support as long as the
    underlying database driver supports it, even when it's used within an
    abstraction like `database/sql` or Bun.
    bgentry committed May 23, 2024
    Configuration menu
    Copy the full SHA
    4518593 View commit details
    Browse the repository at this point in the history