[postgis-devel] Versioning and History

[George Silva]

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