We want to get back this result
{
project: {
id: 1,
name: "First Project",
description: "Create a cool website",
client: {
id: 1,
name: "First Client"
We want to get back this result
{
project: {
id: 1,
name: "First Project",
description: "Create a cool website",
client: {
id: 1,
name: "First Client"
[ | |
{ "firstName" : "Daniel" | |
, "lastName" : "Díaz" | |
, "age" : 24 | |
, "likesPizza" : true | |
} | |
, | |
{ "firstName" : "Rose" | |
, "lastName" : "Red" | |
, "age" : 39 |
Scenario 1, this i think models a real life scenario of how an api would evolve over time and we can test it it's actually possible to model versioning using shcemas
Start with 3 schemas that hold the versions of the api 1,2,3
#------------------------------------------------------------------------------ | |
# ERROR REPORTING AND LOGGING | |
#------------------------------------------------------------------------------ | |
# - Where to Log - | |
log_destination = 'csvlog' # Valid values are combinations of | |
# stderr, csvlog, syslog, and eventlog, | |
# depending on platform. csvlog | |
# requires logging_collector to be on. |
---- this query si meant to return something similar to information_schema.view_column_usage | |
---- but only the columns that are actually in the SELECT part of the result | |
---- and the name of the column as used in the view definition | |
-- list only the columns from views | |
WITH view_columns AS ( | |
SELECT | |
c.oid AS view_oid, | |
a.attname::information_schema.sql_identifier AS column_name |