Re: Best way to populate nested composite type from JSON` - Mailing list pgsql-general

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.
--