[postgis-devel] Re: PostGIS 1.0 & JDBC locking (WFS)

[strk at refractions.net]

Sorry if I insist on this, but postgis has never had 
the locking support in its releases (correct me if I'm wrong).
The only thing present in postgis-0.9 code was a trigger
function, but neither enabling of it nor accessors functions
nor documentation was provided.

I continue to think this is far from postgis-specific as the
exact same set of functions would work generally for any 
row-level auth-based multi-session locking.

If we implement the trigger as a plpgsql function instead of
a C function the full support could be in a single .sql file
and be sourced as part of the installation of geoserver, or
distributed with postgis but not installed by default.

What do people think about this ?

(I'm just trying to keep postgis clean)

--strk;

PS: I won't receive messages posted on geotools-devel or
    geoserver-devel, please include me in the header if
    you respond there.

On Wed, Mar 23, 2005 at 10:18:55AM -0800, Jody Garnett wrote:
> strk at refractions.net wrote:
> 
> Strk - I am not really going to be answer many questions this month. 
> Hopefully those pdf files, and the WFS specification, can another take.
> 
> One final resource - of where I want this to go:
> - 
> http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/feature/LockRequest.html
> - 
> http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/feature/LockResponse.html
> - 
> http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/feature/Transaction.html
> 
> The javadocs for these files show the most complete example of these 
> locks in use.
> Jody
> 
> >1. Is transaction-level authorization acquisition a requirement ?
> > 
> >
> Yes, we need an authorization that will last for the result of a 
> transaction. The authroization string must be user supplied (ie not 
> generated) because we need to use the same authorization string with 
> other data sources besides postgis.
> 
> >	BEGIN;
> >	SELECT HaveAuthorization('key');
> >	UPDATE ....
> >	* OK
> >	END;
> > 
> >
> The above is the correct use.
> 
> >2. Is full statement failure on partial auth failure a requirement ?
> >
> >Ie:
> >	-- full failure
> >	UPDATE ... 3 rows ...
> >	* One row needs authorization, NONE updated
> > 
> >
> Both are supported by the specification (and it is a *bad* idea), a data 
> source gets to describe what kind of failure it supports. The only 
> stable thing is the NONE updated  option (full failure).
> 
> >3. Is it a problem changing function names ?
> > 
> >
> You can change the functions names, the last revision we explicitly 
> mentioned "Features" and "FeautreID" because it was an explicit locking 
> system we are implementing (aka a WFS Feature Lock), rather than a 
> generic system.
> 
> Jody