Nathan Van der Auwera created an issue |
[REST API] Ability to store/read extra meta-data fields to retain a “version” number |
Issue Type: |
Wish |
---|---|
Assignee: |
Unassigned |
Created: |
24/Jan/20 1:32 PM |
Priority: |
Medium |
Reporter: |
I am a rails developer, and we created a platform where the rails website/database is used to feed into geoserver.
In rails the database is managed using “migrations”. Since this data feeds into geoserver, and I manage different servers which are at various stages in the development/deployment process, I implemented a similar process for managing geoserver. In short:
- I remember the set of executed/applied geoserver-migrations in the database
- a geoserver migration is described using a small SLD and applied using the REST API
- migrations which have not been applied will be executed and their numbers are stored for future reference
I guess you can imagine the problems: since I store the executed migrations in the database, this can account for syncing problems. E.g. I restore the database from a backup, or I switch to a different geoserver instance (without copying the complete datastore) and now my migrations is out of sync.
So I was wondering if there is some kind of mechanism to be able to store extra meta-data in geoserver? Which is accessible from the REST API.
In the workspace we already have some metadata: the primary contact and the address (not accessible from the API?), it would be useful for me to be able to add some keys with a value?
I can see two scenarios for me, for this:
- either I only store the latest/last migration (only 1 number needed)
- or, as in rails migrations, we can store
allexecuted migration-numbers (seems better but probably harder?)
I am pretty sure I am not the only one having trouble maintaining different geoserver instances (DEV/TEST/QA/PROD) but maybe my approach is somewhat unique.
For me, since database migrations go hand in hand with geoserver migration, this seemed to be a logical approach. Not sure if this is a preferred/adviced approach, so maybe there are better ways?
But having specific/user-defined metadata in the workspace might be useful for more people?
So to summarise I see a need/potential for adding meta-data
- is this already possible and am I overlooking it?
- if not, is this something you are willing to consider?
- I think I can make time for this, how would I go about adding this? E.g. add an extension? (maybe I should google that)
Kind regards,
Nathan
Get Jira notifications on your phone! Download the Jira Cloud app for Android or iOS |
|
This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100118-sha1:1eaaf92) |