persistent-mysql deprecation warnings

[darthdeus]

While trying to figure out how to use persistent-mysql I found out that Connection is deprecated in favor of SqlBackend, and is actually defined as a type alias, though it is still used in type declarations in persistent-mysql (https://github.com/yesodweb/persistent/blob/master/persistent-mysql/Database/Persist/MySQL.hs#L87).

I'm not sure if I'm missing something, or if this can be just changed to SqlBackend?

[snoyberg]

Looks like it could just be changed.

On Sun, Feb 1, 2015, 5:59 PM Jakub Arnold notifications@github.com wrote:

While trying to figure out how to use persistent-mysql I found out that
Connection is deprecated in favor of SqlBackend, and is actually defined
as a type alias, though it is still used in type declarations in
persistent-mysql (
https://github.com/yesodweb/persistent/blob/master/persistent-mysql/Database/Persist/MySQL.hs#L87
).

I'm not sure if I'm missing something, or if this can be just changed to
SqlBackend?

—
Reply to this email directly or view it on GitHub
#355.

[darthdeus]

Thanks! I have a related question though. By using withMySQLConn defaultConnectInfo, I can get (SqlBackend -> SqlPersistM a) -> SqlPersistM a. If I have an expression to run such as runMigration migrateAll :: SqlPersistM (), I'd need a way to connect the two pieces together.

At first I thought I could use runSqlConn or runSqlPersistM, but these are only SqlPersistM a -> SqlBackend -> IO a, which isn't compatible with the withMySQLConn, which takes a function.

Following the book, it seems something like this should be possible

withMySQLConn defaultConnectInfo $ \c -> liftIO $ runSqlConn (runMigration migrateAll) c

but at this point I just get a SqlPersistM (), which I can't run with runSqlPersistM, since that requires SqlBackend again, and there is no way to get to the backend, except with withMySQLConn ... which is what caused the problem in the beginning.

Is there some way in which I'm misusing the withMySQLConn? It seems that this should be rather easy, but I can't find a way for the types to align.

edit: One thing to note, if I could simply do withMySQLConn defaultConnectInfo $ \c -> runSqlPersistM (runMigration migrateAll) c that would solve the problem, but withMySQLConn requires a MonadLogger instance, which there isn't for IO, so this variant doesn't typecheck as well.

[snoyberg]

I think you're overly constraining withMySQLConn; it will work with any
instance of MonadBaseControl. The kind of code you've shown above should
work. I can't be certain why it's not without seeing the error messages
you're getting. But I don't think this issue is the right place to discuss
such things.

On Sun Feb 01 2015 at 6:19:44 PM Jakub Arnold notifications@github.com
wrote:

Thanks! I have a related question though. By using withMySQLConn
defaultConnectInfo, I can get (SqlBackend -> SqlPersistM a) ->
SqlPersistM a. If I have an expression to run such as runMigration
migrateAll :: SqlPersistM (), I'd need a way to connect the two pieces
together.

At first I thought I could use runSqlConn or runSqlPersistM, but these
are only SqlPersistM a -> SqlBackend -> IO a, which isn't compatible with
the withMySQLConn, which takes a function.

Following the book http://www.yesodweb.com/book/persistent, it seems
something like this should be possible

withMySQLConn defaultConnectInfo $ \c -> liftIO $ runSqlConn (runMigration migrateAll) c

but at this point I just get a SqlPersistM (), which I can't run with
runSqlPersistM, since that requires SqlBackend again, and there is no way
to get to the backend, except with withMySQLConn ... which is what caused
the problem in the beginning.

Is there some way in which I'm misusing the withMySQLConn? It seems that
this should be rather easy, but I can't find a way for the types to align.

—
Reply to this email directly or view it on GitHub
#355 (comment).

[darthdeus]

Thanks for replying, I've written up everything in this StackOverflow question. I'd be really happy if you could point me in the right direction.

[gregwebs]

@darthdeus is there something that should be done for this issue or should it be closed?

[darthdeus]

@gregwebs looks like it was fixed in #371, closing the issue