RFC: pipes-opaleye

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: pipes-opaleye

Bas van Dijk-2
Hello,

I just started playing with pipes and I really like it so far. For my first project I would like to create a Producer for opaleye query results. I came up with the following:

  https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs

Is that the correct way of doing it? What can be improved?

Thanks,

Bas

--
Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Gabriel Gonzalez
Looks pretty straightforward to me

The only other suggestion I'd provide is to also provide a `Managed` version of the same `Producer`, with this type:

    query
        :: (Default QueryRunner columns haskells, MonadIO m, MonadMask m)
        => Connection -> Query columns -> Managed (Producer haskells m ())

Also, since it doesn't use the return value, you could even use the simpler `ListT` type instead:

    query
        :: (Default QueryRunner columns haskells, MonadIO m, MonadMask m)
        => Connection -> Query columns -> Managed (ListT m haskells)

... and then you can always convert that back to a `Producer` using `enumerate` if necessary

On Jul 29, 2017, at 2:54 PM, Bas van Dijk <[hidden email]> wrote:

Hello,

I just started playing with pipes and I really like it so far. For my first project I would like to create a Producer for opaleye query results. I came up with the following:

  https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs

Is that the correct way of doing it? What can be improved?

Thanks,

Bas

--

--
Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Bas van Dijk-2
I like the ListT suggestion and just implemented it.

I don't understand how I can get rid of SafeT by using Managed. You're talking about Managed from your managed package right?

On 30 July 2017 at 15:58, Gabriel Gonzalez <[hidden email]> wrote:
Looks pretty straightforward to me

The only other suggestion I'd provide is to also provide a `Managed` version of the same `Producer`, with this type:

    query
        :: (Default QueryRunner columns haskells, MonadIO m, MonadMask m)
        => Connection -> Query columns -> Managed (Producer haskells m ())

Also, since it doesn't use the return value, you could even use the simpler `ListT` type instead:

    query
        :: (Default QueryRunner columns haskells, MonadIO m, MonadMask m)
        => Connection -> Query columns -> Managed (ListT m haskells)

... and then you can always convert that back to a `Producer` using `enumerate` if necessary

On Jul 29, 2017, at 2:54 PM, Bas van Dijk <[hidden email]> wrote:

Hello,

I just started playing with pipes and I really like it so far. For my first project I would like to create a Producer for opaleye query results. I came up with the following:

  https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs

Is that the correct way of doing it? What can be improved?

Thanks,

Bas

--

--

--
Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Oliver Charles-3

You might also want to look at streaming-postgresql-simple for similar prior art.

Ollie


On Sun, 30 Jul 2017, 3:47 pm Bas van Dijk, <[hidden email]> wrote:
I like the ListT suggestion and just implemented it.

I don't understand how I can get rid of SafeT by using Managed. You're talking about Managed from your managed package right?

On 30 July 2017 at 15:58, Gabriel Gonzalez <[hidden email]> wrote:
Looks pretty straightforward to me

The only other suggestion I'd provide is to also provide a `Managed` version of the same `Producer`, with this type:

    query
        :: (Default QueryRunner columns haskells, MonadIO m, MonadMask m)
        => Connection -> Query columns -> Managed (Producer haskells m ())

Also, since it doesn't use the return value, you could even use the simpler `ListT` type instead:

    query
        :: (Default QueryRunner columns haskells, MonadIO m, MonadMask m)
        => Connection -> Query columns -> Managed (ListT m haskells)

... and then you can always convert that back to a `Producer` using `enumerate` if necessary

On Jul 29, 2017, at 2:54 PM, Bas van Dijk <[hidden email]> wrote:

Hello,

I just started playing with pipes and I really like it so far. For my first project I would like to create a Producer for opaleye query results. I came up with the following:

  https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs

Is that the correct way of doing it? What can be improved?

Thanks,

Bas

--

--

--

--
Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Tom Ellis-4
In reply to this post by Bas van Dijk-2
On Sat, Jul 29, 2017 at 11:54:33PM +0200, Bas van Dijk wrote:
> I just started playing with pipes and I really like it so far. For my first
> project I would like to create a Producer for opaleye query results. I came
> up with the following:
>
>   https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs
>
> Is that the correct way of doing it? What can be improved?

I'm curious about all the MVar business.  Is this a typical thing to do in
the pipes world?  I thought there would be a more pure approach.

--



Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Oliver Charles-3
It's necessary because the type of `fold` given in `postgresql-simple` is fairly useless. It can't be massaged into the necessary shape of a free monad, so the best we can do is recover the steps by repeatedly pushing into an MVar and blocking. In my streaming-postgresql-simple library I write the fold's my self (using libpq) to avoid needing to introduce concurrency.

On Sun, Jul 30, 2017 at 5:42 PM Tom Ellis <[hidden email]> wrote:
On Sat, Jul 29, 2017 at 11:54:33PM +0200, Bas van Dijk wrote:
> I just started playing with pipes and I really like it so far. For my first
> project I would like to create a Producer for opaleye query results. I came
> up with the following:
>
>   https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs
>
> Is that the correct way of doing it? What can be improved?

I'm curious about all the MVar business.  Is this a typical thing to do in
the pipes world?  I thought there would be a more pure approach.

--

--
Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Tom Ellis-4
Interesting.  I've been wondering what we can do about the type of `fold`.
Are there any strange consequences to generalising to `MonadIO`?  For
example, what happens if we try to use this with `ListT IO`?  I presume it
behaves in a not very useful way.

On Sun, Jul 30, 2017 at 06:42:16PM +0000, Oliver Charles wrote:

> It's necessary because the type of `fold` given in `postgresql-simple` is
> fairly useless. It can't be massaged into the necessary shape of a free
> monad, so the best we can do is recover the steps by repeatedly pushing
> into an MVar and blocking. In my streaming-postgresql-simple library I
> write the fold's my self (using libpq) to avoid needing to introduce
> concurrency.
>
> On Sun, Jul 30, 2017 at 5:42 PM Tom Ellis <
> [hidden email]> wrote:
>
> > On Sat, Jul 29, 2017 at 11:54:33PM +0200, Bas van Dijk wrote:
> > > I just started playing with pipes and I really like it so far. For my
> > first
> > > project I would like to create a Producer for opaleye query results. I
> > came
> > > up with the following:
> > >
> > >
> > https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs
> > >
> > > Is that the correct way of doing it? What can be improved?
> >
> > I'm curious about all the MVar business.  Is this a typical thing to do in
> > the pipes world?  I thought there would be a more pure approach.

--



Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Gabriel Gonzalez
Note that you can turn the type of `fold` into a `Turtle.Shell`

The type of `postgresql-simple`'s `fold` forces you to consume the stream exactly once, whereas `Producer`s, `ListT`s, and similar types let you traverse the stream or any element multiple times

`Turtle.Shell` also has the advantage that it has built-in support for `Managed`, however, it has the major disadvantage that you have to consume the stream in its entirety, unlike `Producer`/`ListT` which let you partially consume a stream

On Sun, Jul 30, 2017 at 12:50 PM, Tom Ellis <[hidden email]> wrote:
Interesting.  I've been wondering what we can do about the type of `fold`.
Are there any strange consequences to generalising to `MonadIO`?  For
example, what happens if we try to use this with `ListT IO`?  I presume it
behaves in a not very useful way.

On Sun, Jul 30, 2017 at 06:42:16PM +0000, Oliver Charles wrote:
> It's necessary because the type of `fold` given in `postgresql-simple` is
> fairly useless. It can't be massaged into the necessary shape of a free
> monad, so the best we can do is recover the steps by repeatedly pushing
> into an MVar and blocking. In my streaming-postgresql-simple library I
> write the fold's my self (using libpq) to avoid needing to introduce
> concurrency.
>
> On Sun, Jul 30, 2017 at 5:42 PM Tom Ellis <
> [hidden email]> wrote:
>
> > On Sat, Jul 29, 2017 at 11:54:33PM +0200, Bas van Dijk wrote:
> > > I just started playing with pipes and I really like it so far. For my
> > first
> > > project I would like to create a Producer for opaleye query results. I
> > came
> > > up with the following:
> > >
> > >
> > https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs
> > >
> > > Is that the correct way of doing it? What can be improved?
> >
> > I'm curious about all the MVar business.  Is this a typical thing to do in
> > the pipes world?  I thought there would be a more pure approach.

--

--
Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Oliver Charles-3

Depending on how you do that streaming, that might not be a disadvantage - "single row mode" streaming requires all rows are processed before another query is issued. On my library I use MonadResource to hook into stream destruction and make sure any remaining rows are fetched. Not great, but workable


On Mon, 31 Jul 2017, 2:05 am Gabriel Gonzalez, <[hidden email]> wrote:
Note that you can turn the type of `fold` into a `Turtle.Shell`

The type of `postgresql-simple`'s `fold` forces you to consume the stream exactly once, whereas `Producer`s, `ListT`s, and similar types let you traverse the stream or any element multiple times

`Turtle.Shell` also has the advantage that it has built-in support for `Managed`, however, it has the major disadvantage that you have to consume the stream in its entirety, unlike `Producer`/`ListT` which let you partially consume a stream

On Sun, Jul 30, 2017 at 12:50 PM, Tom Ellis <[hidden email]> wrote:
Interesting.  I've been wondering what we can do about the type of `fold`.
Are there any strange consequences to generalising to `MonadIO`?  For
example, what happens if we try to use this with `ListT IO`?  I presume it
behaves in a not very useful way.

On Sun, Jul 30, 2017 at 06:42:16PM +0000, Oliver Charles wrote:
> It's necessary because the type of `fold` given in `postgresql-simple` is
> fairly useless. It can't be massaged into the necessary shape of a free
> monad, so the best we can do is recover the steps by repeatedly pushing
> into an MVar and blocking. In my streaming-postgresql-simple library I
> write the fold's my self (using libpq) to avoid needing to introduce
> concurrency.
>
> On Sun, Jul 30, 2017 at 5:42 PM Tom Ellis <
> [hidden email]> wrote:
>
> > On Sat, Jul 29, 2017 at 11:54:33PM +0200, Bas van Dijk wrote:
> > > I just started playing with pipes and I really like it so far. For my
> > first
> > > project I would like to create a Producer for opaleye query results. I
> > came
> > > up with the following:
> > >
> > >
> > https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs
> > >
> > > Is that the correct way of doing it? What can be improved?
> >
> > I'm curious about all the MVar business.  Is this a typical thing to do in
> > the pipes world?  I thought there would be a more pure approach.

--

--

--
Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Bas van Dijk-2
Note that I created a PR for opaleye[1] giving it a cursor interface. With it I can write a Producer which doesn't need to fork a thread and push all rows through a MVar.

Bas


On 31 July 2017 at 10:36, Oliver Charles <[hidden email]> wrote:

Depending on how you do that streaming, that might not be a disadvantage - "single row mode" streaming requires all rows are processed before another query is issued. On my library I use MonadResource to hook into stream destruction and make sure any remaining rows are fetched. Not great, but workable


On Mon, 31 Jul 2017, 2:05 am Gabriel Gonzalez, <[hidden email]> wrote:
Note that you can turn the type of `fold` into a `Turtle.Shell`

The type of `postgresql-simple`'s `fold` forces you to consume the stream exactly once, whereas `Producer`s, `ListT`s, and similar types let you traverse the stream or any element multiple times

`Turtle.Shell` also has the advantage that it has built-in support for `Managed`, however, it has the major disadvantage that you have to consume the stream in its entirety, unlike `Producer`/`ListT` which let you partially consume a stream

On Sun, Jul 30, 2017 at 12:50 PM, Tom Ellis <[hidden email]> wrote:
Interesting.  I've been wondering what we can do about the type of `fold`.
Are there any strange consequences to generalising to `MonadIO`?  For
example, what happens if we try to use this with `ListT IO`?  I presume it
behaves in a not very useful way.

On Sun, Jul 30, 2017 at 06:42:16PM +0000, Oliver Charles wrote:
> It's necessary because the type of `fold` given in `postgresql-simple` is
> fairly useless. It can't be massaged into the necessary shape of a free
> monad, so the best we can do is recover the steps by repeatedly pushing
> into an MVar and blocking. In my streaming-postgresql-simple library I
> write the fold's my self (using libpq) to avoid needing to introduce
> concurrency.
>
> On Sun, Jul 30, 2017 at 5:42 PM Tom Ellis <
> [hidden email]> wrote:
>
> > On Sat, Jul 29, 2017 at 11:54:33PM +0200, Bas van Dijk wrote:
> > > I just started playing with pipes and I really like it so far. For my
> > first
> > > project I would like to create a Producer for opaleye query results. I
> > came
> > > up with the following:
> > >
> > >
> > https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs
> > >
> > > Is that the correct way of doing it? What can be improved?
> >
> > I'm curious about all the MVar business.  Is this a typical thing to do in
> > the pipes world?  I thought there would be a more pure approach.

--

--

--

--
Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Bas van Dijk-2
In reply to this post by Tom Ellis-4
Hi Tom,

I now wrote a version which doesn't use a separate thread to push all the rows through an MVar. It's using the new cursor interface that I added to opaleye:


Bas

On 30 July 2017 at 18:42, Tom Ellis <[hidden email]> wrote:
On Sat, Jul 29, 2017 at 11:54:33PM +0200, Bas van Dijk wrote:
> I just started playing with pipes and I really like it so far. For my first
> project I would like to create a Producer for opaleye query results. I came
> up with the following:
>
>   https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs
>
> Is that the correct way of doing it? What can be improved?

I'm curious about all the MVar business.  Is this a typical thing to do in
the pipes world?  I thought there would be a more pure approach.

--

--
Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Tom Ellis-4
Looks really nice!

On Wed, Aug 02, 2017 at 12:46:20AM +0200, Bas van Dijk wrote:

> I now wrote a version which doesn't use a separate thread to push all the
> rows through an MVar. It's using the new cursor interface that I added to
> opaleye:
>
> https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs
>
> On 30 July 2017 at 18:42, Tom Ellis <[hidden email]> wrote:
>
> > On Sat, Jul 29, 2017 at 11:54:33PM +0200, Bas van Dijk wrote:
> > > I just started playing with pipes and I really like it so far. For my
> > > first project I would like to create a Producer for opaleye query
> > > results.  I came up with the following:
> > >
> > >   https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs
> > >
> > > Is that the correct way of doing it? What can be improved?
> >
> > I'm curious about all the MVar business.  Is this a typical thing to do in
> > the pipes world?  I thought there would be a more pure approach.

--



Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Bas van Dijk-2
In reply to this post by Oliver Charles-3
Ollie, your streaming-postgresql-simple is really interesting. I didn't know about "single row mode" streaming[1]. I can imagine it's faster than streaming using a cursor since you don't have to send back a "FETCH FORWARD $chunkSize" command for every chunk that you want to fetch. Instead you only read from a socket and push each result on the stream.


On 30 July 2017 at 16:52, Oliver Charles <[hidden email]> wrote:

You might also want to look at streaming-postgresql-simple for similar prior art.

Ollie


On Sun, 30 Jul 2017, 3:47 pm Bas van Dijk, <[hidden email]> wrote:
I like the ListT suggestion and just implemented it.

I don't understand how I can get rid of SafeT by using Managed. You're talking about Managed from your managed package right?

On 30 July 2017 at 15:58, Gabriel Gonzalez <[hidden email]> wrote:
Looks pretty straightforward to me

The only other suggestion I'd provide is to also provide a `Managed` version of the same `Producer`, with this type:

    query
        :: (Default QueryRunner columns haskells, MonadIO m, MonadMask m)
        => Connection -> Query columns -> Managed (Producer haskells m ())

Also, since it doesn't use the return value, you could even use the simpler `ListT` type instead:

    query
        :: (Default QueryRunner columns haskells, MonadIO m, MonadMask m)
        => Connection -> Query columns -> Managed (ListT m haskells)

... and then you can always convert that back to a `Producer` using `enumerate` if necessary

On Jul 29, 2017, at 2:54 PM, Bas van Dijk <[hidden email]> wrote:

Hello,

I just started playing with pipes and I really like it so far. For my first project I would like to create a Producer for opaleye query results. I came up with the following:

  https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs

Is that the correct way of doing it? What can be improved?

Thanks,

Bas

--

--

--

--

--
Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Bas van Dijk-2
I realise we should also be able to combine cursor streaming and single-result-mode streaming. This would have the advantage of also streaming the results in a chunk from a cursor and, in case of termination, you only need to drain[1] the results for the current chunk.


On 2 August 2017 at 01:13, Bas van Dijk <[hidden email]> wrote:
Ollie, your streaming-postgresql-simple is really interesting. I didn't know about "single row mode" streaming[1]. I can imagine it's faster than streaming using a cursor since you don't have to send back a "FETCH FORWARD $chunkSize" command for every chunk that you want to fetch. Instead you only read from a socket and push each result on the stream.


On 30 July 2017 at 16:52, Oliver Charles <[hidden email]> wrote:

You might also want to look at streaming-postgresql-simple for similar prior art.

Ollie


On Sun, 30 Jul 2017, 3:47 pm Bas van Dijk, <[hidden email]> wrote:
I like the ListT suggestion and just implemented it.

I don't understand how I can get rid of SafeT by using Managed. You're talking about Managed from your managed package right?

On 30 July 2017 at 15:58, Gabriel Gonzalez <[hidden email]> wrote:
Looks pretty straightforward to me

The only other suggestion I'd provide is to also provide a `Managed` version of the same `Producer`, with this type:

    query
        :: (Default QueryRunner columns haskells, MonadIO m, MonadMask m)
        => Connection -> Query columns -> Managed (Producer haskells m ())

Also, since it doesn't use the return value, you could even use the simpler `ListT` type instead:

    query
        :: (Default QueryRunner columns haskells, MonadIO m, MonadMask m)
        => Connection -> Query columns -> Managed (ListT m haskells)

... and then you can always convert that back to a `Producer` using `enumerate` if necessary

On Jul 29, 2017, at 2:54 PM, Bas van Dijk <[hidden email]> wrote:

Hello,

I just started playing with pipes and I really like it so far. For my first project I would like to create a Producer for opaleye query results. I came up with the following:

  https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs

Is that the correct way of doing it? What can be improved?

Thanks,

Bas

--

--

--

--


--
Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Oliver Charles-3
It would have that advantage, but nullifies the other advantage of using a cursor - being able to issue another query at the same time on the same connection handle.

On Wed, Aug 2, 2017 at 12:24 AM Bas van Dijk <[hidden email]> wrote:
I realise we should also be able to combine cursor streaming and single-result-mode streaming. This would have the advantage of also streaming the results in a chunk from a cursor and, in case of termination, you only need to drain[1] the results for the current chunk.


On 2 August 2017 at 01:13, Bas van Dijk <[hidden email]> wrote:
Ollie, your streaming-postgresql-simple is really interesting. I didn't know about "single row mode" streaming[1]. I can imagine it's faster than streaming using a cursor since you don't have to send back a "FETCH FORWARD $chunkSize" command for every chunk that you want to fetch. Instead you only read from a socket and push each result on the stream.


On 30 July 2017 at 16:52, Oliver Charles <[hidden email]> wrote:

You might also want to look at streaming-postgresql-simple for similar prior art.

Ollie


On Sun, 30 Jul 2017, 3:47 pm Bas van Dijk, <[hidden email]> wrote:
I like the ListT suggestion and just implemented it.

I don't understand how I can get rid of SafeT by using Managed. You're talking about Managed from your managed package right?

On 30 July 2017 at 15:58, Gabriel Gonzalez <[hidden email]> wrote:
Looks pretty straightforward to me

The only other suggestion I'd provide is to also provide a `Managed` version of the same `Producer`, with this type:

    query
        :: (Default QueryRunner columns haskells, MonadIO m, MonadMask m)
        => Connection -> Query columns -> Managed (Producer haskells m ())

Also, since it doesn't use the return value, you could even use the simpler `ListT` type instead:

    query
        :: (Default QueryRunner columns haskells, MonadIO m, MonadMask m)
        => Connection -> Query columns -> Managed (ListT m haskells)

... and then you can always convert that back to a `Producer` using `enumerate` if necessary

On Jul 29, 2017, at 2:54 PM, Bas van Dijk <[hidden email]> wrote:

Hello,

I just started playing with pipes and I really like it so far. For my first project I would like to create a Producer for opaleye query results. I came up with the following:

  https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs

Is that the correct way of doing it? What can be improved?

Thanks,

Bas

--

--

--

--


--
Reply | Threaded
Open this post in threaded view
|

Re: RFC: pipes-opaleye

Bas van Dijk-2
Good point.

On 2 August 2017 at 11:02, Oliver Charles <[hidden email]> wrote:
It would have that advantage, but nullifies the other advantage of using a cursor - being able to issue another query at the same time on the same connection handle.

On Wed, Aug 2, 2017 at 12:24 AM Bas van Dijk <[hidden email]> wrote:
I realise we should also be able to combine cursor streaming and single-result-mode streaming. This would have the advantage of also streaming the results in a chunk from a cursor and, in case of termination, you only need to drain[1] the results for the current chunk.


On 2 August 2017 at 01:13, Bas van Dijk <[hidden email]> wrote:
Ollie, your streaming-postgresql-simple is really interesting. I didn't know about "single row mode" streaming[1]. I can imagine it's faster than streaming using a cursor since you don't have to send back a "FETCH FORWARD $chunkSize" command for every chunk that you want to fetch. Instead you only read from a socket and push each result on the stream.


On 30 July 2017 at 16:52, Oliver Charles <[hidden email]> wrote:

You might also want to look at streaming-postgresql-simple for similar prior art.

Ollie


On Sun, 30 Jul 2017, 3:47 pm Bas van Dijk, <[hidden email]> wrote:
I like the ListT suggestion and just implemented it.

I don't understand how I can get rid of SafeT by using Managed. You're talking about Managed from your managed package right?

On 30 July 2017 at 15:58, Gabriel Gonzalez <[hidden email]> wrote:
Looks pretty straightforward to me

The only other suggestion I'd provide is to also provide a `Managed` version of the same `Producer`, with this type:

    query
        :: (Default QueryRunner columns haskells, MonadIO m, MonadMask m)
        => Connection -> Query columns -> Managed (Producer haskells m ())

Also, since it doesn't use the return value, you could even use the simpler `ListT` type instead:

    query
        :: (Default QueryRunner columns haskells, MonadIO m, MonadMask m)
        => Connection -> Query columns -> Managed (ListT m haskells)

... and then you can always convert that back to a `Producer` using `enumerate` if necessary

On Jul 29, 2017, at 2:54 PM, Bas van Dijk <[hidden email]> wrote:

Hello,

I just started playing with pipes and I really like it so far. For my first project I would like to create a Producer for opaleye query results. I came up with the following:

  https://github.com/basvandijk/pipes-opaleye/blob/master/src/Pipes/Opaleye/RunQuery.hs

Is that the correct way of doing it? What can be improved?

Thanks,

Bas

--

--

--

--



--