* Don't indent first line of configuration parser error messages
configurator-pg returns multi-line errors now. Alternatively,
we could indent all the lines.
Specifically, allow base 4.13 which ships with GHC 8.8, as well
as several dependency updates including hasql-transaction 1.0,
swagger 2.5 and warp 3.3.
When having one-to-many relationships like:
person -< message[sender]
person -< message[recipient]
person_detail -< message[sender]
person_detail -< message[recipient]
Where person_detail is a view of person.
This request:
GET "/message?select=*,sender(*)"
Is ambiguous. Both person or person_detail could be embedded.
Until now we have returned the first detected relationship but
now we return a 300 Multiple Choices error with a
descriptive error message asking the user to disambiguate.
This is more helpful for the user and also aids in cases of more
complex relationships.
Two changes:
- tags are now an insert-ordered hashset
- type_ .~ -> type_ ?~ with some magic type inference
This also updates stack.yaml to the newest GHC 8.6 LTS release.
* Update resolver to lts-13.29 and add lock file to repository
* Upgrade stack version
* Save cache after building dependencies only to have faster feedback loop when tests fail
* Move private functions from QueryBuilder to a separate Private module
* Move more functions over to private trying to make compilation consume less memory
* Split private in 4 modules
* Remove unused LambdaCase pragma
* Add profile to memory-tests.sh so it can find postgrest executable
* Move save dependencies before building and running tests for faster feedback loop
* Relax some cabal upper bounds
Primarily based on building against GHC 8.6.5 with stackage lts-13.23.
* Add swagger2 upper bound
With swagger2 2.4, we get a number of errors like the following:
src/PostgREST/OpenAPI.hs:58:11: error:
• Couldn't match type ‘Maybe
(SwaggerType 'Data.Swagger.Internal.SwaggerKindSchema)’
with ‘SwaggerType 'Data.Swagger.Internal.SwaggerKindSchema’
arising from a functional dependency between:
constraint ‘HasType
Schema (SwaggerType 'Data.Swagger.Internal.SwaggerKindSchema)’
arising from a use of ‘type_’
instance ‘HasType
Schema
(Maybe (SwaggerType 'Data.Swagger.Internal.SwaggerKindSchema))’
at <no location info>
• In the first argument of ‘(.~)’, namely ‘type_’
In the second argument of ‘(&)’, namely ‘type_ .~ SwaggerObject’
In the first argument of ‘(&)’, namely
‘(mempty :: Schema) & description .~ tableDescription t
& type_ .~ SwaggerObject’
|
58 | & type_ .~ SwaggerObject
| ^^^^^
* Require base 4.9 / GHC 8.0.1
The DuplicateRecordFields extension, which is used here,
was introduced with GHC 8.0.
* Set cabal lower bounds
These are based on building against stackage lts-7.24 / GHC 8.0.1.
* Set cabal upper bounds, and truncate lower bounds
These are primarily based on the output of `cabal bounds`, with a good
build against GHC 8.6.5. Some test dependencies were missing; these
were filled out based on a build against stackage nightly.
Also I truncated lower bounds to the third level, since that is what
`cabal bounds` seems to suggest anyway.
* Format postgrest.cabal using stylish-cabal
* Sort build-depends list
- allows queries to refer to current_setting('app.settings.foo') to retrieve variables
- useful for 12-factor apps (app data can be in environment)
- provides workaround for AWS Relational Database Service (RDS) not
allowing `ALTER DATABASE SET 'app.[KEY]' TO '[VALUE]'` on database.
It was detected that Aeson encoding had high memory usage when
the json payload was large, around x60 the payload size.
With this change we get around x10 payload size memory usage.
The encodeUtf8(when doing a Text -> ByteString with `toS`) function
on a large payload also contributed to the high memory usage.
Main idea to reduce the memory usage was to let the ByteString coming
from the request body go to the database unchanged.
steve-chavez