Hi, sorry for the noise, but I'm looking for feedback on finagle/finagle-postgres#128 I'd just like to know if it's something that will be considered for merging before adding more commits...
@jeremyrsmith I've added the remaining bits and also undone the API breakage. Please take a look finagle/finagle-postgres#128
@dangerousben @leonmaia Any chance we can get a
0.12.0 release with the latest changes (https://github.com/finagle/finagle-postgres/compare/v0.11.0...master)?
Sorry - I'm not using postgres at work, moved to mysql and been very busy for the last year working with Kafka. So I'm not with the time to be 'very' active here.
I'll merge the update PRs from scala-stewart and tag a new release.
v0.12.0 has been published @plaflamme, thanks a lot for the contribution! Release notes: https://github.com/finagle/finagle-postgres/releases/tag/v0.12.0
and then hopefully get around to reviewing some of the outstanding human PRs, including the above
does anyone know if scala-steward requires your dependencies to be specified in the most simple way possible, rather than (eg) having a
val finagleVersion that you apply later elsewhere?
I assume it it probably does, but can't really find any documentation to the effect
I have this error : unresolved dependency: io.github.finagle#finagle-postgres_2.13;0.4.0-SNAPSHOT: not found
also 0.4.0-SNAPSHOT is ancient, looks like we need to update the guide
@leonmaia if you have the time could be worth cutting a release that includes 2.13 support?
Any objections to switching the use of a travis-provided PgSQL to an embedded one? This is an example finagle/finagle-postgres#186 of converting a test to rely on the embedded version. It makes running tests entirely self contained...
Yeah, sorry I should have mentioned. This is the actual postgresql binary embedded in a jar. At runtime, it extracts the correct one for the platform and starts it pointing a temporary directory. The main drawbacks are: harder to change the postgres version since that's dictated by the test dependency and potential runtime issues when extracting / running. But the upside is pretty big IMO since you can just do
sbt test and things "just work".
Hmm, so the upside is that it eliminates some one-time setup for contributors to run the integration tests (but if you're contributing you probably have postgres installed locally anyway right)? And the downside is that it makes it impossible for CI to run integration tests against different versions of postgres (which AFAIK isn't something finagle-postgres does anyway). So I guess I'm ambivalent about it :grinning:
Well, I suppose it's about being self-contained. With this approach, there is no need to assume that a contributor has pgsql running anywhere (nor that their environment variables are setup correctly). In fact, this assumption had to be clarified recently: finagle/finagle-postgres#157 For supporting multiple versions, it's solvable and I'm willing to take a stab at it if this is something that has a chance of being merged. In fact, I'll submit an example in the existing PR. The ultimate upside would be that
sbt it:test locally behaves the same as within CI with no additional setup as well as test against multiple pgsql versions.
@jeremyrsmith I've updated the PR to use a different embedded pgsql (a fork from the first one) that makes multi-version testing easier. The PR uses one sbt project per pgsql major version and runs the
IntegrationSpec against that, there are alternate approaches I suspect, but this one works without too much trouble. The end result is testing against 9, 10 and 11 locally simply through sbt test.
See here finagle/finagle-postgres#186
would be interested to know whether we can support TLS with an embedded pg, the current CI build doesn't test it
@plaflamme are you around? I'm trying to debug these intermittent travis failures and it's possible it has something to do with your changes to ValuesSpec in #187 (which I have merged, breaking the build in the process)
do I need to use the
query command?
I found this: finagle/finagle-postgres#42
But it's very strange to use
But it's very strange to use
select when the underlying query is inserting
in any case I have a new problem where for some reason I get this ChannelClosedException: ChannelException at remote address: localhost/127.0.0.1:5432. Remote Info: Upstream Address: Not Available, Upstream id: Not Available
, Downstream Address: localhost/127.0.0.1:5432, Downstream label: postgres, Trace Id: d5b4617f06faa23e.d5b4617f06faa23e<:d5b4617f06faa23e
I'm hosting a psql server locally with docker compose on 5432 port tried with the following configuration:
Postgres.Client()
.withCredentials("postgres", "pass")
.database("postgres")
.newRichClient(Config.POSTGRES_URL)