Skip to content

Use resourcet-pool#1163

Merged
parsonsmatt merged 4 commits intoyesodweb:masterfrom
brandonchinn178:resourcet-pool
Jan 6, 2021
Merged

Use resourcet-pool#1163
parsonsmatt merged 4 commits intoyesodweb:masterfrom
brandonchinn178:resourcet-pool

Conversation

@brandonchinn178
Copy link
Contributor

Before submitting your PR, check that you've:

After submitting your PR:

  • Update the Changelog.md file with a link to your PR
  • Bumped the version number if there isn't an (unreleased) on the Changelog
  • Check that CI passes (or if it fails, for reasons unrelated to your change, like CI timeouts)

Copy link
Collaborator

@parsonsmatt parsonsmatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This MR isn't entirely compatible - resourcet-pool depends on newer version of resource-pool and resourcet than persistent does. I'm curious if persistent is wrong here, or if you can relax the bounds in resourcet-pool.

Overall I like it - factoring out functionality like this is generally a good thing.

- ./persistent-qq

extra-deps:
- resourcet-pool-0.1.0.0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need this in stackage if we're going to depend on it and continuing offering persistent as a Stackage library.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just pushed it to Hackage. I'll put in on Stackage later today. I won't merge this PR until that's done

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@parsonsmatt Ok I'm adding it here: commercialhaskell/stackage#5758

When it gets merged and the library is added to nightly, what should I change in this PR? If I just remove extra-deps from stack.yaml here, stack build will no longer work because stack.yaml uses lts-14.27, right?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll need to keep it in extra-deps, but any nightly checks shouldn't need it starting soon.

_ -> P.putResource localPool res

return $ fst <$> mkAcquireType (P.takeResource pool) freeConn
unsafeAcquireSqlConnFromPool = MonadReader.asks poolToAcquire
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation of poolToAcquire appears to be copied from this function. This function has an unsafe prefix, but the function you're copying doesn't have any mention of unsafety in any way.

Looking at the docs, I think the "unsafety" might be coming from the fact that this Acquire doesn't start/commit a transaction. So it may be no real concern.

Copy link
Contributor Author

@brandonchinn178 brandonchinn178 Nov 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I basically just factored out this function. I agree, it seems like the unsafety is persistent-wise, not resource-pool-wise.

@brandonchinn178
Copy link
Contributor Author

This MR isn't entirely compatible - resourcet-pool depends on newer version of resource-pool and resourcet than persistent does. I'm curious if persistent is wrong here, or if you can relax the bounds in resourcet-pool.

What do you mean? It seems like persistent has

                   , resource-pool            >= 0.2.3
                   , resourcet                >= 1.1.10

whereas resourcet-pool has

    , resource-pool >=0.2.1.0 && <0.3
    , resourcet >=1.1.2 && <2

@parsonsmatt
Copy link
Collaborator

This MR isn't entirely compatible - resourcet-pool depends on newer version of resource-pool and resourcet than persistent does. I'm curious if persistent is wrong here, or if you can relax the bounds in resourcet-pool.

What do you mean? It seems like persistent has

                   , resource-pool            >= 0.2.3
                   , resourcet                >= 1.1.10

whereas resourcet-pool has

    , resource-pool >=0.2.1.0 && <0.3
    , resourcet >=1.1.2 && <2

Oh man. I think I was confusing which library I was looking at 😂 Good catch!

@brandonchinn178
Copy link
Contributor Author

@parsonsmatt This was added to nightly: commercialhaskell/stackage#5758. Is there anything else blocking this PR?

@parsonsmatt
Copy link
Collaborator

I fixed CI on master, try merging that in

@brandonchinn178
Copy link
Contributor Author

@parsonsmatt seems to still be failing

@parsonsmatt
Copy link
Collaborator

I don't think you merged master in to this branch - please give that a shot, it should fix CI

@brandon-leapyear
Copy link
Contributor

brandon-leapyear commented Nov 30, 2020

This is an old work account. Please reference @brandonchinn178 for all future communication


@parsonsmatt sorry about that! should be good to go now

@parsonsmatt
Copy link
Collaborator

Yeah, looks good! Just needs the CHANGELOG and version bumps for a release. Should be a patch release since there's no change to the behavior of the code.

@brandonchinn178
Copy link
Contributor Author

Sounds good! How's that?

@parsonsmatt parsonsmatt merged commit f82154f into yesodweb:master Jan 6, 2021
codygman added a commit to codygman/persistent that referenced this pull request Mar 5, 2021
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.

3 participants