George,<br><br>I am glad you are interested in this topic. Sadly, my original questions were cut off and not answered when they should have been so we can continue having a conversation. I am still unclear about whether you want "workspace" or "table" level versioning, etc. The state trees in ArcSDE are workspace-level specifically because it simplifies the answers of a lot of the questions that I asked. <br>
<br>However, even without those answers, I think there is still value on continuing this conversation.<br><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;">
Date: Sat, 5 Dec 2009 12:03:06 -0200<br>
From: George Silva <<a href="mailto:georger.silva@gmail.com">georger.silva@gmail.com</a>><br>
Subject: Re: [postgis-devel] Versioning and Historyu<br>
To: PostGIS Development Discussion<br>
<<a href="mailto:postgis-devel@postgis.refractions.net">postgis-devel@postgis.refractions.net</a>><br>
Message-ID:<br>
<<a href="mailto:9aa147370912050603o3ab92ec2hbee7821927396642@mail.gmail.com">9aa147370912050603o3ab92ec2hbee7821927396642@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
All the tips and considerations are excellent Ragi, but same as<br>
Regina, i'm thinking about Applications, not just database logic.<br>
<br></blockquote><div><br>I am also thinking applications. I don't see how you infer that I am just talking db logic. In fact, the conflict resolution should probably be done by choosing a default conflict resolution policy, and then allowing the application to pick whatever version the user really wants for each individual feature.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A set of rules/triggers would be interesting to start propagating the<br>
changes to child versions, but in some place everything gets hairy,<br>
and that's where the application code must jump in and help.<br>
<br></blockquote><div><br>I wholeheartedly disagree. Besides the conflict resolution, where there is potential advantage of having the application (i.e. the user) override default conflict resolutions, the rest should be automatic. <br>
<br>Maybe I am missing something, but do you have an example of a case in mind where there is an actual advantage of having the reconciliation code be done at the application level over the database? I am interested on hearing this.<br>
<br>On the other hand, delegating the reconciliation code to the database resolves the of the biggest problems - concurrent edits. In ArcGIS GeoDatabase versioning workflows that have multiple editors (more than one) reconciling and posting logic is done in both the client and server and *that* is hard to get right (i.e. hairy). <br>
<br>Databases (well at least good ol' ACID ones) are made specifically to handle this type of stuff.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Not everything can be enforced through the database, and i imagine a<br>
system where the user gets to choose the working version.<br>
<br></blockquote><div> </div><div>Although you are right that not *everything* can be enforced through the database, it is certainly harder - and many times *much* less efficient - to enforce things at the application level, since that usually requires transferring of big chunks of data to the client which usually kill you. I don't think reconciliation of versions is a problem that requires application level "help". Please tell me if you disagree.<br>
<br>I also imagine a system where the user chooses the working version, otherwise what would be the point of this conversation? :) That's the reason I mentioned the set_current_version('myversion') store procedure that would presumably be executed by the user to pick the current version they are working in... just like ArcSDE multiversion views.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If something would be carried out with rules and triggers that means<br>
that the user should edit the parent table (INSTEAD OF), but that<br>
would cause a great deal of confusion, because he would need to load<br>
the main version on a GIS software and edit it from there. Also, when<br>
editing he would only see changes in the versioned tables.<br></blockquote><div><br><br>I never said that. I said they would interact with the views. so they would edit the views and never the parent tables directly. No need to use the methodology you are describing in my scenario.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
A great deal of system logic needs to be considered, in the aspects of<br>
choosing version, showing the correct changes, etc. Also i do _not_<br>
want to duplicate all records for each version. This would be much<br>
easier, but impratical for most serious systems.<br>
<br></blockquote><div><br>I never recommended this. We were always talking about working with deltas.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thanks for your thoughts and i'm still listening.<br>
<br></blockquote><div><br>I am glad you are. I hope my answers don't come out in the wrong tone since that is not my intention (and very easy to get confused in e-mail)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thanks<br>
<br>
George<br>
<br>
On Fri, Dec 4, 2009 at 6:49 PM, Paragon Corporation <<a href="mailto:lr@pcorp.us">lr@pcorp.us</a>> wrote:<br>
> ?> ?And a comment:<br>
><br>
> ?> ?Think *Views*! ... hiding this complexity in views will make your life<br>
> easier plus it will not need changes in clients. Clients connecting to a<br>
> PostgreSQL DB can use the tables like they normally do, and clients that<br>
> want to leverage the versioning aspect of it can use the versioning stored<br>
> procedures (i.e set_current_version('myversion')).<br>
><br>
> ?> ?My two cents,<br>
><br>
> ?> ?- Ragi<br>
><br>
> Just a note.? Views are great, but to many applications they don't see<br>
> primary keys and when they don't sadly views appear?as read-only?even if you<br>
> make them updateable.??Just something to consider, that they are sadly not<br>
> as transparent as they should be. Think geoserver for example.<br>
><br>
> Regina<br>
><br></blockquote><div><br>Hello Regina and thank you so much for joining the conversation. IMHO an application that will not execute edits on an updatable view is an application with a bug :) <br><br>However, you do have a valid point. <br>
<br>Changing the logic of application to be able to edit rows that don't have primary keys is probably a crazy request so I will not go there (I am thinking how all the rows in OGR, for example, require an ObjectID).<br>
<br>Nevertheless, a common scenario will be that the table will still be queriable. In a slightly different scenario, I can see how an application could recognize some sort of versioning registry table (in the spirit of the geometry_columns table) and find out that a view has a column that can be treated as unique and thus allow it to be edited. Versioned-enabled clients would then be able to edit versioned tables, while the rest of the clients would still be able to query in readonly mode.<br>
<br>Think about the alternative of *not* using views. I would always have to append _v1 or _v2 or _v3 to my ALL my tables names to get the right results. It just becomes inconvenient for scripts and such. An that is the scenario where we are talking about workspace-level versioning. If we are talking tables, ugh, I don't even want think about it - it would be horrible.<br>
<br>My 5 cents, and let's keep the conversation going :)<br><br>- Ragi<br><br><br>However, if they somehow recog<br></div></div>