API design and pgapp

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

API design and pgapp

David Welton-3
Hi,

I'm jumping back into the world of Erlang, and among other things,
work on pgapp, a higher level interface for Postgres.

This came up, lately: https://github.com/epgsql/pgapp/issues/22

Which seems to pit two things against one another:

* On one hand, using the process registry to keep track of the Conn
(connection) is not very Erlang-y and might introduce errors.

* That said, it's also nice for things to be composable in the sense
that you can write, say, update_stats() either within the transaction
or outside and have it 'just work' without having to provide both an
update_stats() and update_stats(Conn).

Thoughts? Thanks!
--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: API design and pgapp

Nathaniel Waisbrot
> This came up, lately: https://github.com/epgsql/pgapp/issues/22
>
> Which seems to pit two things against one another:
>
> * On one hand, using the process registry to keep track of the Conn
> (connection) is not very Erlang-y and might introduce errors.
>
> * That said, it's also nice for things to be composable in the sense
> that you can write, say, update_stats() either within the transaction
> or outside and have it 'just work' without having to provide both an
> update_stats() and update_stats(Conn).



I don't think it's a productive addition to that epgsql conversation, but I would write only update_stats/1. A Postgres connection is not a trivial thing like an Erlang process.  On a default installation you only get a couple hundred of them and you can see some unpleasant surprises if you go over. Therefore, I think it's a mistake to not explicitly track your connections in the code.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: API design and pgapp

David Welton-3
Hi,

> I don't think it's a productive addition to that epgsql conversation, but I would write only update_stats/1. A Postgres connection is not a trivial thing like an Erlang process.  On a default installation you only get a couple hundred of them and you can see some unpleasant surprises if you go over. Therefore, I think it's a mistake to not explicitly track your connections in the code.

You could say the same thing about other resources, like, say, memory.
Or write a system that helps the programmer work at a higher level by
setting up some 'good defaults' and managing the underlying resources.
pgapp is the latter kind of system.

--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions