This is handled server side. Subscriptions are more like 'live queries'. The server sends the data to the client only when the result set for the given 'live-query' changes.
While we can get the information on the columns used in a view, we can't infer if the uniqueness properties propagate to the view which guarantee the semantics of relationships.
I guess it might be convenient to do this (determine relationships across views), but the users should be aware of the guarantees offered in this scenario.
Thanks ! If I remember correctly, postgrest was started about the same time we started work on the data service. In fact, both these projects were pushing the limits of the then hasql library with the whole dynamic query generation.
True. That would also mean creating a database user for every application user. The auth service needs to attach more metadata to the users and since postgres does not allow you to reference system catalogs, the two user systems have to be kept in sync. We were not quite certain how this idea of mapping users would pan out when we started building the auth service.
I'm one of the engineers who work on the data service
> about metadata: in Postgrest ..
We don't want to restrict the data service to a particular schema. You can add a table from any schema to be tracked, say information_schema or pg_catalog. In fact, that is how introspection works (you can look at the queries made by the console). This means that the schema cache in memory would be quite large because of the number of tables in information_schema/pg_catalog if we were to auto load all these. There is also the issue that you may not want to expose some tables. We can definitely have a console button which will let you import all the tables in public schema.
Sure, you can infer relationships from the foreign key constraints. But, how would you come up with names that do not conflict with the existing columns? What if you add a new column with the same name as an inferred relationship? With the data service, you can also define relationships on/to views across schemas (1). Making metadata explicit goes with one of our core principles, 'no magic'.
> what postgrest does for protection: a - no fancy joins,
explicit joins are not allowed even with our data service. The joins that happen are the implicit ones because of the relationships. We do the same thing if we need any custom joins/aggregations. Define a view and expose it.
> b -
you can't do anything other than selecting columns and relationships with the api.
> c -
the permission layer can be used to prevent these to some extent (like not allowing an anonymous user to filter on a particular column).
Lee Sedol seemed to be doing well before he went into extra time (as far as I could follow from the commentators). How is it ensured that this is a fair game given the time constraints? I'm guessing adding more computing power to the AlphaGo program should definitely help it in this regard.