Re: Best way to populate nested composite type from JSON`

From: Chris Travers <chris(dot)travers(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Best way to populate nested composite type from JSON`
Date: 2013-09-14 00:52:26
Message-ID: CAKt_Zfs4N4TxmV3HiADU11LY4aTvCMKOGpa5Uew=H1k4+pcDJw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Sep 13, 2013 at 8:51 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:

>
>
> What's your client side stack?
>
> merlin
>

Right now we are using something a little lighter weight in terms db
discovery but it doesn't handle this situation very well. I am the author
of the PGObject space on CPAN and currently we are using what was the
ancestor of PGObject::Simple::Role which does discovery based on function
names and argument names.

The PGObject namespace is basically a namespace for database-driven object
oriented mapping systems. The idea is that you can have an object model
defined in the database (and with data logic coded in SQL), which gets
discovered and used by the application at run-time. It is PG-only of
course.

Unfortunately the problem is that once you go to any significantly complex
data structure, my current discovery efforts fall apart. This means that
the application/db contract becomes more brittle and fewer things can
change without having to fix both sides. For example, currently, for
processing payments we have two different implementations which take two
different ways of trying to solve this problem and neither tolerates any
semantic change to the arguments. Currently these are among our least
maintainable stored procedures.

So my effort is in building a new service locator module (probably
something like PGObject::CompositeType) that would pull in properties of a
composite type as properties of an object model, and also create methods
dynamically based on functions taking that type as a first argument. The
only real problem is serializing an arbitrarily complex composite type to
the backend for processing. If JSON worked it would save me a lot on the
client side. But if not.... The key requirement is that the data
structures on the client would be pulled from named composite types on the
server.

--
Best Wishes,
Chris Travers

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2013-09-14 02:07:45 Re: Postgres 9.2.4 "Double Precision" Precision
Previous Message Bill Moran 2013-09-13 23:46:04 Re: Using LDAP for PostgreSQL permissions/authentication