[postgis-devel] Re: PostGIS 1.0 & JDBC locking (WFS)
strk at refractions.net
strk at refractions.net
Wed Mar 23 12:57:40 PST 2005
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
More information about the postgis-devel
mailing list