[postgis-devel] Versioning and History

[Ragi Y. Burhum]

From: George Silva <georger.silva at gmail.com>

> Subject: [postgis-devel] Versioning and History
> To: postgis-devel at postgis.refractions.net
> Message-ID:
>        <9aa147370912040740g56f29df1j3c7a1b3aeeaad7da at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hello PostGis developers,
>
> I was wondering if a Versioning framework would be something too
> complicated to develop.
>
> I think the PostGIS part of the "thing" is quite easy and
> straighforward and i am wiling to take it further. I already even
> developed some ideas. But for versioning to work consistently software
> adaptation must also happen.
>
> Perhaps, if a basic versioning layer is availuable and published, each
> software using some guidelines, could implement their own interfaces
> of versioning.
>
> What do you think of these issues?
>
> Here are some thoughts i had so far. Everyone is welcome to comment,
> critisize and give advice.
>
> versioning_information
> id | parent_id | schema_name | table_name | geometry_name | created_in
> | last_update | owner
> -
> - when the user creates a version, a check occurs, and see if the
> version already has a parent id
> - if not:
> - parent id created, child id and table created
> - if yes:
> - check what is the parent_id, and create a new table, inserting all
> records from the child1 table
>
> id | parent_id | schema_name | table_name | geometry_name | created_in
> | last_update | owner
> 0      null         foo          foo           foo            xxxx
>     -           user
> 1      0            foo       foo_v1           foo            xxxx
>     now()       user_who_created
> 2      1            foo       foo_v1_v2        foo            xxxx
>     now()       user_who_created
> 3      0            foo       foo_v3           foo            xxxx
>     now()       user_who_versioned
>
> - multiple versions of the same parent table can be created
> - reconciles can only be propagated from child to imediate parent version
> - permissions should be estabished for a single user and for the user
> who versioned the table
> - no other permissions should be granted
> - changes should all be logged. reconciliation must be done trou
> changelogs, not copying all the table
> - the versioning system should create and populate a table of
> conflicts, at the moment of reconcile. perhaps a empty field called
> "solution" could be added, and when the user fills that, a trigger
> would know what to do with it (keep child feature or keep parent
> feature)
>
> I appreciate your attention,
>
>
> --
> George R. C. Silva
>
> Desenvolvimento em GIS
> www.sextantegeo2.blogspot.com
>
>
Sounds like you are thinking *table*-level versioning as opposed to
"workspace"-level versioning (what ESRI does). I am not pro/con of using one
over the other, but let me ask you some questions:

- How would you handle foreign key relationship enforcement / or integrity
using this methodology?
- Why do you think it is important to only be able to reconcile to your
immediate parent? Note that many source code version control systems as well
as ESRI's versioning system do no impose this restriction.
- How do you know that a version has been reconciled?
- Do you want to make a distinction between the act of of "reconciling" (i.e
pulling the changes and going through conflict resolutions of conflicting
rows) and the act of "posting" (i.e you are done - so pushing your changes
back).

And a comment:

Think *Views*! ... hiding this complexity in views will make your life
easier plus it will not need changes in clients. Clients connecting to a
PostgreSQL DB can use the tables like they normally do, and clients that
want to leverage the versioning aspect of it can use the versioning stored
procedures (i.e set_current_version('myversion')).

My two cents,

- Ragi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20091204/06399c66/attachment.html>