On Fri, Sep 13, 2013 at 7:52 PM, Chris Travers <chris.travers@gmail.com> wrote:
> On Fri, Sep 13, 2013 at 8:51 AM, Merlin Moncure <mmoncure@gmail.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.
Huh. Interesting factoid: I cowrote (see:
http://libpqtypes.esilo.com/man3/pqt-composites.html) what remains
today the only effective way to send complex types to the server. For
non-'C' languages, json support will probably be the way to go once
the server can handle json deserialization better.
Right now whenever possible I'm deploying json directly to javascript
heavy applications with ultrathin middlewares with most of the
interesting backend processing (as you envisage) happening in the
database; It's powerful and it works.
merlin
