martin config expose only specific schema #47
Comments
|
Hi @Captain-Oski! Thanks for the idea, but I'm not sure how do you want it to be. Could you please provide an example for this? |
|
Thank you for replying so quickly : it could be something like this alongside the config.yaml: So that it would only targets all the tables and functions into a specific schema. I founding it extremely verbose and difficult to maintain an config file when you need multiple tables and functions but need to hide from the public numerous tables. I guess one could migrate the needed tables and functions into a new database instance but ... |
|
I see the problem with config verbosity, but schema sources don't fit very well yet. I'll think about how to simplify config to expose schemas, thanks! |
|
The #380 makes this possible, but would require us to think how to add it to configuration |
|
Implemented in #510, pending a few more PR megres |
Can now handle several additional Postgres functions to get a tile, plus tons of small fixes ### Multiple result variants * `getmvt(z,x,y) -> [bytea,md5]` (single row with two columns) * `getmvt(z,x,y) -> [bytea]` (single row with a single column) * `getmvt(z,x,y) -> bytea` (value) ### Multiple input parameter variants * `getmvt(z, x, y)` or `getmvt(zoom, x, y)` (all 3 vars must be integers) * `getmvt(z, x, y, url_query)`, where instead of `url_query` it could be any other name, but must be of type JSON ### Breaking * srid is now the same type as PG -- `i32` * renamed config vals `table_sources` and `function_sources` into `tables` and `functions` ### Features and fixes * if postgis is v3.1+, uses margin parameter to extend the search box by the size of the buffer. I think we should make 3.1 minimal required. * fixes feature ID issue from #466 * fixes mixed case names for schemas, tables and columns, functions and parameter names per #389 ### Notes * More dynamic SQL generation in code instead of using external SQL files. Those should only be used when they are not parametrized. * The new function/table discovery mechanism: query for all functions in the database, and match up those functions with the ones configured (if any), plus adds all the rest of the un-declared ones if discovery mode is on. * During table and function discovery, the code generates a map of `(PgSqlInfo, FunctionInfo)` (or table) tupples containing SQL needed to get the tile. * Auto-discovery mode is currently hidden - the discovery is on only when no tables or functions are configured. TBD - how to configure it in the future * The new system allows for an easy way to auto-discover for the specific schemas only, solving #47 * predictable order of table/function instantiation * bounding boxes computed in parallel for all tables (when not configured) * proper identifier escaping * test cleanup fixes #378 fixes #466 fixes #65 fixes #389
Configuration refactoring to allow future schema filtering. This partially solves #47, but it does not expose the configuration to the user just yet.
|
@stepankuzmin and I at the last minute realized that we don't have a clear agreement on how to specify schema configuration list for this feature. See #512 -- can use your feedback on the best way to configure, as well as possible usecases you can think of |
|
added in #546 |
Hello ! Thank you for the superbe work !
I am wondering if we could expose only a entire schema instead of exposing one table at a time ?
Thank you
The text was updated successfully, but these errors were encountered: