Re: Postgres Pain Points 2 ruby / node language drivers

From: Chris Travers <chris(dot)travers(at)gmail(dot)com>
To: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Postgres Pain Points 2 ruby / node language drivers
Date: 2016-08-14 10:55:41
Message-ID: CAKt_Zft2ANhj4NZ4MozuxRwKUfQEdZ_v8-RBpeF=5WpJ=c15MQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, Aug 14, 2016 at 12:35 PM, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
wrote:

> On Fri, Aug 12, 2016 at 01:32:33PM +0200, Chris Travers wrote:
>
> >>> My preference is stored procedures plus service locators
> >>
> >> Would you care to elaborate a little on the latter (service locators) ?
> >>
> >
> > Sure. What I prefer to do is to allow for a (cacheable) lookup on the
> > basis of some criteria, either:
> > 1. Function name or
> > 2. Function name and first argument type
> >
> > This assumes that whichever discovery criteria you are using leads to
> > uniquely identifying a function.
> >
> > Then from the argument list, I know the names and types of the arguments,
> > and the service locator can map them in. This means:
> >
> > 1. You can expose an API which calls arguments by name rather than just
> > position, and
> > 2. You can add arguments of different types without breaking things as
> > long as it is agreed that unknown arguments are passed in as NULL.
>
> Maybe I am a bit dense. Can you please give an example ?
>

Ok. Two ways of doing this based on different discovery criteria.. The
first would be:

CREATE FUNCTION person_save(in_id int, in_first_name text, in_last_name
text, in_date_of_birth date)
RETURNS person LANGUAGE ... as $$ ... $$;

Then you have a service locator that says "I have a person object and want
to call person_save." It then looks up the function argument names and
calls it something like this:

SELECT * FROM person_save(?, ?, ?, ?)

with parameters
$object->id, $object->first_name, $object->last_name, $object->date_of_birth

The second approach is to tie to the first argument type (think 'self' in
Python).

In this case, we'd have a function defined like this:

CREATE FUNCTION save(person) RETURNS person LANGUAGE ... AS $$ ...$$;

Then we have a different service locator that maps this to the safe
function as:

SELECT * FROM save(?::person);

with a argument that is basically:

serialize_to_record_form($object)

Of course that's just the start. To make this really usable you have to add
some additional functionality but that should be enough to describe the
process.

>
> Thanks,
> Karsten
> --
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

--
Best Wishes,
Chris Travers

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chris Travers 2016-08-14 10:58:12 Re: Any reasons for 'DO' statement not returning result?
Previous Message Karsten Hilbert 2016-08-14 10:35:30 Re: Postgres Pain Points 2 ruby / node language drivers