GeoTools
  1. GeoTools
  2. GEOT-3770

Specification of a FeatureVersioning Interface

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Trivial Trivial
    • Resolution: Won't Fix
    • Affects Version/s: 8.0-M1
    • Fix Version/s: None
    • Component/s: api
    • Labels:
      None

      Description

      It would be useful to have a FeatureVersioning interface that can be used to ensure that any versioned development will be follow a similar api.

        Activity

        Hide
        Andrea Aime added a comment -
        Having just an API without 3 implementation to validate it (or at least a supported implementation) would just add to the current cemetery of failed attempts. Having an API is certainly a good idea, pushing it to supported status without a corresponding supported implementation is not.
        Show
        Andrea Aime added a comment - Having just an API without 3 implementation to validate it (or at least a supported implementation) would just add to the current cemetery of failed attempts. Having an API is certainly a good idea, pushing it to supported status without a corresponding supported implementation is not.
        Hide
        Jody Garnett added a comment - - edited
        Your point about discussion is a good one Andrea; we need to start somewhere and a proposal is one of the ways we can tease out developer activities that have been going on off-list.

        I think we have three versions to compare for this:
        1) original postgis-versioned (even if it is not updated it is a solid take on the requirements)
        2) arcsde versioned tables (hoping for Gabriel's input here).
        3) "geogit" Gabriel's skunkworks project which walter has been looking at

        The other things we could look at are:

        * wfs 2.0 / ISO 19143:2010
        * oracle long term transaction
        * any others?

        One thing that is troubling when comparing is the different uses of the works "version". I am especially sensitive as it may effect Justin's WFS 2.0 implementation; if WFS 2.0 is assuming the Oracle / ESRI definition of Version it is a fair bit different then my earlier assumption.

        * Version: ESRI and Oracle use this similar to the subversion concept of a branch (i.e. you can get on a "version" of the entire dataset and rock out making changes safe in the knowledge that the changes are isolated from the mainline. They both have some workflow around taking changes from one "version" to another and do comparisons between them.
        * Revision: ESRI has the concept of turning on "history" or "archive" for a "Version"; the most common set up is a single main "Version" which has "History" turned on allowing you to check changes over time and query back in time to see how things were yesterday or last week.

        Perhaps something to ask about on standards@osgeo.org.
        Show
        Jody Garnett added a comment - - edited Your point about discussion is a good one Andrea; we need to start somewhere and a proposal is one of the ways we can tease out developer activities that have been going on off-list. I think we have three versions to compare for this: 1) original postgis-versioned (even if it is not updated it is a solid take on the requirements) 2) arcsde versioned tables (hoping for Gabriel's input here). 3) "geogit" Gabriel's skunkworks project which walter has been looking at The other things we could look at are: * wfs 2.0 / ISO 19143:2010 * oracle long term transaction * any others? One thing that is troubling when comparing is the different uses of the works "version". I am especially sensitive as it may effect Justin's WFS 2.0 implementation; if WFS 2.0 is assuming the Oracle / ESRI definition of Version it is a fair bit different then my earlier assumption. * Version: ESRI and Oracle use this similar to the subversion concept of a branch (i.e. you can get on a "version" of the entire dataset and rock out making changes safe in the knowledge that the changes are isolated from the mainline. They both have some workflow around taking changes from one "version" to another and do comparisons between them. * Revision: ESRI has the concept of turning on "history" or "archive" for a "Version"; the most common set up is a single main "Version" which has "History" turned on allowing you to check changes over time and query back in time to see how things were yesterday or last week. Perhaps something to ask about on standards@osgeo.org .
        Hide
        Jody Garnett added a comment -
        This proposal was withdrawn
        Show
        Jody Garnett added a comment - This proposal was withdrawn

          People

          • Assignee:
            Unassigned
            Reporter:
            Walter Deane
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: