* feat: added a draft of an issue form
* fixed a validation issue
* finished up the templates
* used austins phrasing
* Applied comments from the code review
Co-authored-by: Austin Bonander <austin.bonander@gmail.com>
* Applyed more suggestions from code review
Co-authored-by: Austin Bonander <austin.bonander@gmail.com>
* Broke the environment up into multiple fields
* boiled the FR-fields down to a description and an breaking change field
* fixed an unique id issue
---------
Co-authored-by: Austin Bonander <austin.bonander@gmail.com>
* chore: create 0.8.3 release
* fix: prevent dead-branch warning from Clippy in query macros
cc #3595
* fix: move `#[allow]` from previous commit to the `if` block
* feat: add geometry line
* fix: point vs line
* fix: try regular comparison for line
* fix: undo point comparison change
* fix: regular comparison for array lines
* fix: remove line array test
* feat(mysql): support configuring the timezone via url
* test: add test case for mysql with timezone
---------
Co-authored-by: lo <lo@los-MacBook-Pro.local>
When PgListener's underlying connection is closed, try_recv() will
return Ok(None) and reconnect on the next call. In this case, user code
is supposed to reload its state from the database (or otherwise handle
potentially missing messages). However, if the user code uses another
database connection to do so then there is a period between when the
state is reloaded and PgListener's connection is re-established where
notifications are lost without any indication that this has happened.
This commit changes PgListener to eagerly reconnect by default. At the
suggestion of @abonander on discord, I have also included an option to
switch back to the old behaviour in the case where someone was depending
on it.
Now, if the connection is closed then, by default, user code can do
whatever it needs to do in order to recover and any notifications
emitted in the meantime will be waiting for it when it is done.
query_as.rs: 230 mismatched bracket.
query_as.rs: 230 move TIMESTAMP to TIMESTAMPTZ to match type time::OffsetDateTime.
query_as.rs: 241, 251, 260 move i64 to i32 to match postgres type `INT4`.
* feat: point
* test: try if eq operator works for arrays of geometries
* fix: re-introduce comparison
* fix: test other geometry comparison
* test: geometry array equality check
* test: array match for geo arrays geo match for geo only
* fix: prepare geometric array type
* fix: update array comparison
* fix: try another method of geometric array comparison
* fix: one more geometry match tests
* fix: correct query syntax
* test: geometry test further
* impl AnyQueryResult for Sqlite and MySQL
* fix MySQL AnyQueryResult
* fix MySQL AnyQueryResult
* fix manifest
* rewrite `use` and address implementation concerns
* Implement Acquire for PgListener
* Add a test which checks that PgListener implements Acquire
* Drop unnecessary call to `.acquire()`
* Rename test channel to avoid conflict with other tests
* fix(sqlx-postgres): macro could not understand pg interval array type
* refactor(sqlx-postgres): move pg interval array types closer to other array types
* Add a "sqlite-unbundled" feature that dynamically links to system libsqlite3.so library
* update README abouot the newly-added `sqlite-unbundled` feature
* Update README.md to make it clear with bulleted list
Co-authored-by: Austin Bonander <austin.bonander@gmail.com>
* more cfg feature updates
Co-authored-by: Austin Bonander <austin.bonander@gmail.com>
* update documentation in sqlx-sqlx/src/lib.rs too
and also mention possible build time increasement.
* cargo fmt
* Add "sqlite-unbundled" feature to sqlx-cli
* Add sqlite-unbundled to gituhb actions tests
* cfg(feature = "sqlite") => cfg(any(feature = "sqlite", feature = "sqlite-unbundled"))
* fix
* CI: make sqlite-unbundled tests workaround required-features
by duplicating the relevant test section
* use an internal "_sqlite" feature to do the conditional compilation
---------
Co-authored-by: Austin Bonander <austin.bonander@gmail.com>
This isn't a solution for #3484, as that seems to be an issue with privileges on the user's side. However, in the process of figuring that out, I realized we never explicitly test password-less auth.