Why: 1. PropertyDataStore is handy for testing GeoServer 2. It would be good to have a reference implementation of ResourceId that does not require the setup of "GeoGit" 3. Versioned PostGIS is stuck
Implementation approach is to use a side car "foo.history" file. The file can be added to during commit() using simple append from the transaction state diff.
In the interests of keeping this simple we will use a format similar to that provided by the RFC. We will use a "timestamp" created during commit to mark up each entry. This will serve as our magic "version" string required by ResourceId; it will also serve to let us handle the data range based a queries.
fid|version=value|value2|value2|value3
We have a number of ResourceID scenarios to handle:
1) Query all history for a specific FID
This is easy we can can traverse the history file in order; be remembering the "last" version we will be able to return the correct ResourceID information with a date range:
"version5" is the latest value represented in the main property file. * When we return a ResourceID for index 3 we will build a ResourceId using:
Date(previousVersion));
2) Query a specific "index"
Handled in a similar manner as above; in this case we will need to count the number of times fid encountered in order
3. Query using "previous" or "next" or date range...
These ones require us to hold on to the previous unparsed feature content; on the off chance it ends up being the one requested (i.e. via previous or date range).
Environment
None
Activity
Jody Garnett
March 6, 2017 at 10:43 PM
This is a new feature, that could be used to ensure the geotools library works correctly prior to geogig integration. Now that geogig integration is being done in earnest it would once again be handy to have this implementation on hand to reproduce any errors found.
Implement history support for PropertyDataStore (based on ResourceID https://github.com/geotools/geotools/wiki/resourceid ).
Why:
1. PropertyDataStore is handy for testing GeoServer
2. It would be good to have a reference implementation of ResourceId that does not require the setup of "GeoGit"
3. Versioned PostGIS is stuck
Implementation approach is to use a side car "foo.history" file. The file can be added to during commit() using simple append from the transaction state diff.
In the interests of keeping this simple we will use a format similar to that provided by the RFC. We will use a "timestamp" created during commit to mark up each entry. This will serve as our magic "version" string required by ResourceId; it will also serve to let us handle the data range based a queries.
We have a number of ResourceID scenarios to handle:
1) Query all history for a specific FID
This is easy we can can traverse the history file in order; be remembering the "last" version we will be able to return the correct ResourceID information with a date range:
From the above example:
"version5" is the latest value represented in the main property file.
* When we return a ResourceID for index 3 we will build a ResourceId using:
2) Query a specific "index"
Handled in a similar manner as above; in this case we will need to count the number of times fid encountered in order
3. Query using "previous" or "next" or date range...
These ones require us to hold on to the previous unparsed feature content; on the off chance it ends up being the one requested (i.e. via previous or date range).