[postgis-devel] [PostGIS] #343: History Table Enhancements

[PostGIS]

#343: History Table Enhancements
----------------------------+-----------------------------------------------
 Reporter:  pimpaa          |       Owner:  pimpaa       
     Type:  defect          |      Status:  new          
 Priority:  medium          |   Milestone:  PostGIS 2.0.0
Component:  postgis         |     Version:  trunk        
 Keywords:  History Tables  |  
----------------------------+-----------------------------------------------

Comment(by robe):

 George,

 Sorry its taken me until now to look at this.  I hope you haven't lost
 interest.

 I've put what is currently in trunk in the documentation, but I found some
 issues.  Some of which I think you may have already fixed in your latest.

 Can you attach your latest version to this ticket and I'll cut in and
 retest.

 http://www.postgis.org/documentation/manual-svn/Extras.html#History_Table

 One issue I came across is that the history table didn't seem to log my
 update correctly.  It had put in an INSERT event when I did a ST_SetPoint
 of a geometry.

 Some other things I would like changed.

 1) the postgis_install_history function shouldn't return void.  It should
 behave like populate_geometry_columns etc. returning a description of what
 was created and added. http://www.postgis.org/documentation/manual-
 svn/Postgis_Install_History.html

 2) The postgis_enable_history function.
 http://www.postgis.org/documentation/manual-
 svn/Postgis_Enable_History.html
 I kind of like that it returns a boolean so I'm a bit torn.  I think
 though to be consistent with the rest of the code base, it should return a
 text description too of the rules that were added, the history table that
 was created and so forth.

 As far as Mark's comments go about reinventing the wheel.  I haven't
 really had a look at pgfoundry and I like the idea of having the generic
 versioning issue restated with spatial in mind.  I don't think the other
 solutions do that and its a bit of a leap to bring the two together and a
 common request in PostGIS newsgroup.

 I do know that nowadays rules are kind of frowned upon, but I think for
 bulk loading or massive editing, they are still better than triggers , but
 I'll have to do some more serious tests.

 Also I'm not too concerned about this not being terribly polished.  I'm
 thinking of the extras section of PostGIS (and the manual) as both drop-in
 small utilities you can use to solve common GIS problems with PostGIS  as
 well as a seed to build more robust solutions to common problems.  Once
 people understand the problem being solved and how you have solved it then
 only then can people make it better.  What better way to voice that
 purpose than in the official docs.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/343#comment:6>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.