From: George Silva <<a href="mailto:georger.silva@gmail.com">georger.silva@gmail.com</a>><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Subject: [postgis-devel] Versioning and History<br>
To: <a href="mailto:postgis-devel@postgis.refractions.net">postgis-devel@postgis.refractions.net</a><br>
Message-ID:<br>
<<a href="mailto:9aa147370912040740g56f29df1j3c7a1b3aeeaad7da@mail.gmail.com">9aa147370912040740g56f29df1j3c7a1b3aeeaad7da@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hello PostGis developers,<br>
<br>
I was wondering if a Versioning framework would be something too<br>
complicated to develop.<br>
<br>
I think the PostGIS part of the "thing" is quite easy and<br>
straighforward and i am wiling to take it further. I already even<br>
developed some ideas. But for versioning to work consistently software<br>
adaptation must also happen.<br>
<br>
Perhaps, if a basic versioning layer is availuable and published, each<br>
software using some guidelines, could implement their own interfaces<br>
of versioning.<br>
<br>
What do you think of these issues?<br>
<br>
Here are some thoughts i had so far. Everyone is welcome to comment,<br>
critisize and give advice.<br>
<br>
versioning_information<br>
id | parent_id | schema_name | table_name | geometry_name | created_in<br>
| last_update | owner<br>
-<br>
- when the user creates a version, a check occurs, and see if the<br>
version already has a parent id<br>
- if not:<br>
- parent id created, child id and table created<br>
- if yes:<br>
- check what is the parent_id, and create a new table, inserting all<br>
records from the child1 table<br>
<br>
id | parent_id | schema_name | table_name | geometry_name | created_in<br>
| last_update | owner<br>
0 null foo foo foo xxxx<br>
- user<br>
1 0 foo foo_v1 foo xxxx<br>
now() user_who_created<br>
2 1 foo foo_v1_v2 foo xxxx<br>
now() user_who_created<br>
3 0 foo foo_v3 foo xxxx<br>
now() user_who_versioned<br>
<br>
- multiple versions of the same parent table can be created<br>
- reconciles can only be propagated from child to imediate parent version<br>
- permissions should be estabished for a single user and for the user<br>
who versioned the table<br>
- no other permissions should be granted<br>
- changes should all be logged. reconciliation must be done trou<br>
changelogs, not copying all the table<br>
- the versioning system should create and populate a table of<br>
conflicts, at the moment of reconcile. perhaps a empty field called<br>
"solution" could be added, and when the user fills that, a trigger<br>
would know what to do with it (keep child feature or keep parent<br>
feature)<br>
<br>
I appreciate your attention,<br>
<br>
<br>
--<br>
George R. C. Silva<br>
<br>
Desenvolvimento em GIS<br>
<a href="http://www.sextantegeo2.blogspot.com" target="_blank">www.sextantegeo2.blogspot.com</a><br>
<br></blockquote><div> <br>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:<br>
<br>- How would you handle foreign key relationship enforcement / or integrity using this methodology?<br>- 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.<br>
- How do you know that a version has been reconciled? <br>- 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).<br>
<br>And a comment:<br><br>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')).<br>
<br>My two cents,<br><br>- Ragi<br></div></div>