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

Add Acquire based interfaces for connections. #984

Merged
merged 3 commits into from
Jan 28, 2020

Conversation

merijn
Copy link
Contributor

@merijn merijn commented Nov 6, 2019

Add Acquire based interface for starting transactions and getting
connections from a Pool for use in MonadResource instances that are not
MonadUnliftIO, such as Conduit.

Before submitting your PR, check that you've:

After submitting your PR:

  • Update the Changelog.md file with a link to your PR
  • Check that CI passes (or if it fails, for reasons unrelated to your change, like CI timeouts)

@merijn
Copy link
Contributor Author

merijn commented Nov 6, 2019

The LTS-9 looks to be due to a different with being in scope/resourcet having a different type in that version?

I don't get the MySQL error in nightly, seems to be unrelated?

@merijn
Copy link
Contributor Author

merijn commented Nov 6, 2019

LTS-9 failure is indeed due to ResourceT not being based on MonadUnliftIO in that version, not really sure how we could work around that.

MySQL error in nightly appears to be a parse error in timestamps (which doesn't seem remotely related to anything I changed).

@parsonsmatt
Copy link
Collaborator

MySQL error in nightly appears to be a parse error in timestamps (which doesn't seem remotely related to anything I changed).

I suspect that it's because the instance Read UTCTime became more strict, requiring the Z suffix. I had to fix similar errors in esqueleto recently.

LTS-9 failure is indeed due to ResourceT not being based on MonadUnliftIO in that version, not really sure how we could work around that.

lts-9 is GHC 8.0.2, which is out of the "support 3 major versions" release policy. I'd be OK with dropping support for this.

A compatibility module that had some CPP and used MonadBaseControl.. would be disgusting but could work.

@merijn
Copy link
Contributor Author

merijn commented Nov 6, 2019

A compatibility module that had some CPP and used MonadBaseControl.. would be disgusting but could work.

Not sure that'd even work, because this is part of the visible persistent API, since there's no way to guarantee that every MonadBaseControl IO instance has a corresponding MonadUnliftIO and vice versa, afaict.

@merijn
Copy link
Contributor Author

merijn commented Nov 27, 2019

@parsonsmatt What would dropping lts-9 support entail, just deleting the lts-9 line from .travis.yml?

I'd like to see this and #983 merged and making it onto Hackage (although, since I'd also like to bump the SQLite version shipped, perhaps a new Hackage release should wait until I open a PR for that).

@merijn
Copy link
Contributor Author

merijn commented Dec 15, 2019

@parsonsmatt Ping?

I'm not really sure what dropping lts-9 support entails beyond deleting the tests from .travis.yml, additionally I'd (ideally) like to see #983 and #991 merged and released before the busy holiday season starts :)

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 is great. Thanks!

-- on a connection that cannot be done within a transaction, such as VACUUM in
-- Sqlite.
--
-- @since 2.10.5
Copy link
Collaborator

Choose a reason for hiding this comment

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

<3 docs

@@ -28,15 +86,16 @@ import Database.Persist.Sql.Raw
runSqlPool
:: (MonadUnliftIO m, BackendCompatible SqlBackend backend)
=> ReaderT backend m a -> Pool backend -> m a
runSqlPool r pconn = withRunInIO $ \run -> withResource pconn $ run . runSqlConn r
runSqlPool r pconn = with (acquireSqlConnFromPool pconn) $ runReaderT r
Copy link
Collaborator

Choose a reason for hiding this comment

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

The change from runSqlConn to runReaderT drops the logic around transactions and exception handling. Why'd this get changed?

Suggested change
runSqlPool r pconn = with (acquireSqlConnFromPool pconn) $ runReaderT r
runSqlPool r pconn = with (acquireSqlConnFromPool pconn) $ runSqlConn r


-- | Like 'runSqlPool', but supports specifying an isolation level.
--
-- @since 2.9.0
runSqlPoolWithIsolation
:: (MonadUnliftIO m, BackendCompatible SqlBackend backend)
=> ReaderT backend m a -> Pool backend -> IsolationLevel -> m a
runSqlPoolWithIsolation r pconn i = withRunInIO $ \run -> withResource pconn $ run . (\conn -> runSqlConnWithIsolation r conn i)
runSqlPoolWithIsolation r pconn i =
with (acquireSqlConnFromPoolWithIsolation i pconn) $ runReaderT r
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same here - runSqlConn does all the transaction stuff, so runReaderT here voids that safety. (Man I really need to newtype SqlPersistT ...)

Suggested change
with (acquireSqlConnFromPoolWithIsolation i pconn) $ runReaderT r
with (acquireSqlConnFromPoolWithIsolation i pconn) $ \conn -> runSqlConnWithIsolation r conn i

Copy link
Collaborator

Choose a reason for hiding this comment

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

Wait, no, I think I see what's going on here. You've moved that responsibility into the Acquire interface. So runSqlConn has it's own logic for handling exceptions, and that logic is now sort of duplicated into the Acquire interface.

This is fine. Ignore the suggestions. I've reviewed the relevant code and as far as I can tell the behavior will be identical.

(restore $ connRollback conn' getter)
restore $ connCommit conn' getter
return x
runSqlConn r conn = with (acquireSqlConn conn) $ runReaderT r
Copy link
Collaborator

Choose a reason for hiding this comment

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

😂 teaches me to review a PR before at least skimming it fully

@parsonsmatt
Copy link
Collaborator

@merijn OK, we've dropped support for lts-9 in the latest master - can you merge that in and get CI green? Then we can get this + your other SQLite PR out the door.

Thanks!

Add Acquire based interface for starting transactions and getting
connections from a Pool for use in MonadResource instances that are not
MonadUnliftIO, such as Conduit.
Turns out it's needed to do somethings using SQLite and there's no point
in not exporting it and making users reimplement it themselves.
@merijn
Copy link
Contributor Author

merijn commented Jan 6, 2020

@parsonsmatt hmmm, mongodb seems to fail for some reason?

@merijn
Copy link
Contributor Author

merijn commented Jan 6, 2020

Which seems weird, as it works in your master and the failure seems to be caused by MonadFail, which I certainly didn't touch...

@parsonsmatt
Copy link
Collaborator

yeah the mongodb library probably just changed and since we don't have an upper bound it is going bonkers.

@merijn
Copy link
Contributor Author

merijn commented Jan 7, 2020

yeah the mongodb library probably just changed and since we don't have an upper bound it is going bonkers.

I can make another PR with an upperbound on mongodb to get the tests passing and rebase on top of that...

@parsonsmatt parsonsmatt added this to the 2.10.5 milestone Jan 28, 2020
@parsonsmatt parsonsmatt merged commit 01b1269 into yesodweb:master Jan 28, 2020
@parsonsmatt
Copy link
Collaborator

Released in persistent-2.10.5, thanks so much! 😄

@merijn merijn deleted the persistent-acquire branch February 11, 2020 09:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants