[postgis-devel] Versioning and Historyu

[Ragi Y. Burhum]

George,

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.

However, even without those answers, I think there is still value on
continuing this conversation.

Date: Sat, 5 Dec 2009 12:03:06 -0200
> From: George Silva <georger.silva at gmail.com>
> Subject: Re: [postgis-devel] Versioning and Historyu
> To: PostGIS Development Discussion
>        <postgis-devel at postgis.refractions.net>
> Message-ID:
>        <9aa147370912050603o3ab92ec2hbee7821927396642 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> All the tips and considerations are excellent Ragi, but same as
> Regina, i'm thinking about Applications, not just database logic.
>
>
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.


> A set of rules/triggers would be interesting to start propagating the
> changes to child versions, but in some place everything gets hairy,
> and that's where the application code must jump in and help.
>
>
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.

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.

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).

Databases (well at least good ol' ACID ones) are made specifically to handle
this type of stuff.


> Not everything can be enforced through the database, and i imagine a
> system where the user gets to choose the working version.
>
>
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.

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.



> If something would be carried out with rules and triggers that means
> that the user should edit the parent table (INSTEAD OF), but that
> would cause a great deal of confusion, because he would need to load
> the main version on a GIS software and edit it from there. Also, when
> editing he would only see changes in the versioned tables.
>


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.


> A great deal of system logic needs to be considered, in the aspects of
> choosing version, showing the correct changes, etc. Also i do _not_
> want to duplicate all records for each version. This would be much
> easier, but impratical for most serious systems.
>
>
I never recommended this. We were always talking about working with deltas.



> Thanks for your thoughts and i'm still listening.
>
>
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)


> Thanks
>
> George
>
> On Fri, Dec 4, 2009 at 6:49 PM, Paragon Corporation <lr at pcorp.us> wrote:
> > ?> ?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
> >
> > Just a note.? Views are great, but to many applications they don't see
> > primary keys and when they don't sadly views appear?as read-only?even if
> you
> > make them updateable.??Just something to consider, that they are sadly
> not
> > as transparent as they should be. Think geoserver for example.
> >
> > Regina
> >
>

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 :)

However, you do have a valid point.

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).

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.

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.

My 5 cents, and let's keep the conversation going :)

- Ragi


However, if they somehow recog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20091206/8cf24ad1/attachment.html>