Based on feedback from users and contributors, Pyrseas now sports two enhancements.
Multi-line String Formatting
Up to Pyrseas 0.6, long textual elements such as view definitions, function source text and long object comments, would usually be shown in the YAML output as quoted strings with embedded newlines. Here are two examples from the autodoc database:
description: "This schema stores a list of products and information\n about the\
definition: " SELECT DISTINCT product.product_id, product.product_code, product.product_description\n\
\ FROM warehouse.inventory\n JOIN product.product USING (product_id);"
As you can imagine, this was particularly unsatisfactory for complex functions and views. Thanks to preliminary work by Andrey Popp, Pyrseas 0.7 will be able to format these elements in YAML block style. The above elements will be shown as follows:
This schema stores a list of products and information
about the product
SELECT DISTINCT product.product_id, product.product_code, product.product_description
JOIN product.product USING (product_id);
Thanks to testing by Josep Martínez, 0.7 will also properly display and handle such strings even when they include non-ASCII characters such as accented characters. For example, in 0.6, “Martínez” would be shown as “Mart\xEDnez”. In 0.7, the output will be the original UTF-8 string.
Directory of Database Objects
Pyrseas 0.6 has a single format for output by dbtoyaml or input into yamltodb: a single YAML-formatted file. This becomes a problem when your database has hundreds or more tables, functions, etc (let alone 409,994 tables and counting!). Furthermore, as dbtoyaml and yamltodb are intended to assist with database version control, your team may want to store individual object specifications in your version control system, or you may want to diff individual objects.
The 0.7 --directory option to dbtoyaml and yamltodb allows you to split the YAML spec into multiple files in a directory (or folder) tree. For example, using the dbtoyaml -d option on the autodoc database results in the following tree (shown under Linux using ls -RF):
schema.inherit/ schema.public/ schema.warehouse/
schema.inherit.yaml schema.public.yaml schema.warehouse.yaml
table.tab1b.yaml table.tab1.yaml table.taba.yaml table.tabb.yaml
function.worker.yaml sequence.product_product_id_seq.yaml table.product.yaml
sequence.store_store_id_seq.yaml table.inventory.yaml table.store.yaml
As can be seen, each schema gets its own directory wherein are stored each object belonging to that schema. In addition to schemas, the root level also stores non-schema owned objects such as foreign data wrappers and extensions (the latter can be placed in a schema, but are not owned by it).
The directory tree and multi-line string formats are still under review, so I’d like to encourage you to test both enhancements and provide feedback.