Re: Postgres Pain Points 2 ruby / node language drivers

On Fri, Aug 12, 2016 at 11:24 AM, Daevor The Devoted <dollien(at)gmail(dot)com>
wrote:

>
>
> On Fri, Aug 12, 2016 at 10:58 AM, Andreas Joseph Krogh <andreas(at)visena(dot)com
> > wrote:
>
> Could you elaborate on this method? Or direct me to docs describing it in
> more detail? I'm quite interested in this approach, but would like to see
> what amount of overhead (development and maintenance) this might result in.
>
>
There is overhead, of course but sometimes it cannot be avoided. In a
large scientific programming project I helped with, we were using Perl and
DBIx::Class and we had to partition a table because of autovacuum and
planner considerations (autovacuum not keeping up on one large table, and
partition key dramatically affecting which indexes were useful). You can't
just get this to "just work" with an orm. So we added a mapping layer

What you do is create a view, and then add your insert/update/delete logic
to triggers which allow the view to actually proxy to the other tables
properly. Then you use your view as the base relation your ORM hits. Matt
Trout had pointed me to that direction some time earlier and it came in
really handy.

The same basic approach can be used to create a mapping layer generally.

But again, if you are primarily worried about development time, then that
is more important, usually, than information management as a whole.

--
Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more