postgrest / postgrest Goto Github PK

It currently says

{"error":"Failed reading: satisfyElem"}

Show a better parse error to the user.

We need to identify columns that get their values from a postgres sequence. A GUI should not prompt for values of such columns.

For instance a column default value of false is reported as "false" which is incorrect.

Right now the access problem raises a postgres exception which reveals that a table does indeed exist. We should be more sneaky.

The idea is that the client requests

application/vnd.you.com+format; version=n

and this makes n the schema used when accessing /:table

Use rel="describedby" link header in the regular get response

https://www.iana.org/assignments/link-relations/link-relations.xml
https://www.mnot.net/blog/2012/10/29/NO_OPTIONS

Also include rel="describes" in the description url link headers.

To enforce consistent style for would-be contributors, let's make hlint failures break the build. Could throw in a cabal build as well to make sure the code compiles.

the ones that angular-paginate-anything sends

If the post contains an array of objects, write them to the db all at once.

It was introduced by 2f584be

The range 0-0 means that one results was returned, namely the zeroth row.

We can use wai middleware for this
http://hackage.haskell.org/package/wai-middleware-catch-0.3.6/docs/Network-Wai-Middleware-Catch.html

We need to detect specifically the postgres exceptions and include all the info such as the error code and description.

no need to define toRow and fromRow, just use json

whether with command line options or a configuration file

postgresql-simple provides a quoter

This will allow the db to cache and re-use query plans.

/:table?col=val&col2=val2

I was thinking that if { col1...coln } constitute a (possibly compound) primary key then the response would be a single object rather than an array.

/items?c=eq:1&b=eq:2&a=eq:3 should specify a canonical version of itself with filters in alphabetical order.

Content-Location: /items?a=eq:3&b=eq:2&c=eq:1

This helps caches work.

Right now test/fixtures/schema.sql is a postgres dump and includes commands that cause unnecessary code churn and merge conflicts as we work. We should rewrite it all with clean hand-written sql and continue to modify it that way.

To /items?primary_key=bla

If the primary key does not yet exist this should create the record. All columns must be specified in the payload. If they are not, the server should return a 400 with a body explaining they attempted a non-idempotent action with a PUT.

https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#HSTS_mechanism_overview

We shouldn't turn this on in development because our cert is self-signed and the browser will forbid site access.

Currently every query is executed more than once -- first to safely interpolate strings and then to run the generated query.

The response currently looks like this:

{"pkey":["id"],"columns":{"lastname":{"precision":null,"updatable":true,"schema":"1","name":"lastname","type":"character varying","maxLen":255,"nullable":true,"position":2},"firstname":{"precision":null,"updatable":true,"schema":"1","name":"firstname","type":"character varying","maxLen":255,"nullable":true,"position":1}

It would be helpful for columns to return an array since I don't know the column names in advance.

@DrBoolean discovered that when his app requests OPTIONS /table with cors headers he doesn't get back the table structure JSON but instead gets a blank body. Looks like wai-cors is interfering. @adambaker is there a way to configure the middleware to pass the body through?

It is potentially unsafe

POST /items should return 201 with location header pointing at the url of the created item (e.g. /items?primary_key=bar).

Query params are not permitted. To replace an existing resource use PUT. To update multiple, use PATCH. If params are provide the server should send a 400 response.

We'll handle 202 (accepted) delayed creation in a different issue.

Currently we include some nice schema info for a table in the OPTIONS payload, but we are lacking the real headers that HTTP expects.

Authorization will use a designated schema, with a designated table to authenticate users. Eventually, we would like this table to be general enough to support most common authentication strategies. For this feature, we will support username/password authentication. This table will have:

1. identifier
2. encrypted password
3. salt
4. authorization role.

For authorization, we'll have each request authenticate, then before executing any action specified by the request, change roles to the role recovered from column 4 above, and then reset the role on the connection at the end of the request.

The type of an enum is currently listed as USER-DEFINED and gives no clue to acceptable values.

In OPTIONS /table column view it gives false hope of being able to change the value for users who don't have permissions.

If the client requests / with the right accept headers, use graphviz to serve a graphical representation of the tables and key relations.

If the (lack of) range request causes no limiting to happen then return 200 rather than 206.

Currently it selects a range from the table and then applies the where clause to that sub-range. It should apply the where clause to the whole table and then apply the range.

Use Network.URI (isURI)

For the OPTIONS verb we should be outputting an industry standard to say the type of the response json as well as the parameters and versions accepted.

populateSql :: Connection -> QuotedSql -> IO String

is what was once called pgFormat. As you can see it returns a string of the sql ready to execute. We could make a populateAndExecSql function that executes it as an embedded query to save on db roundtrips.

It should be 500.

It's possible to have such a table in postgres. I added a demo table called no_pk to the testing fixture which we can use to test this feature. Right now posts to this table work, but the Location header link replies with /no_pk? because the query params are generated from the (possibly compound) primary key. I am thinking the best solution is to include every single column as a constraint in the link. Even though it may return more than one row, it is the best we can do.

We want quick travis builds to accelerate our pull-request workflow

The app currently blocks the requests but returns a 200 which is inaccurate.

Currently it gives a 400 with postgres error

execute: PGRES_FATAL_ERROR: ERROR:  relation "1.foo" does not exist
LINE 1: ...n(array_agg(row_to_json(t))) from ( select * from "1".foo  L...
                                                             ^

If we add an exception catching middleware we can detect the particular code for this error and do it there.

Convert

selectAll :: T.Text -> Connection -> IO JSON.Value

to

selectAll :: T.Text -> Connection -> IO ByteStream

Perhaps use some kind of accept header content negotiation in the request for this.

https://stackoverflow.com/questions/25475502/including-created-resource-in-http-post-response

Determine a nice JSON format for it and include proper http status code

Right now it is hard coded to use the database dbapi_test and schema base.