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

strk@anonymised.com wrote:

Thank you Jody, I do have a better understanding of the problem.

BTW: do the pdf document existing or "intentional" stuff ?

Opps here is a bit more recent on the intentional stuff ...

By this time we had broken down and turned these into specific "feature locks", and fids are now strings etc.

psql locktest2

------------------------------------------------------------------------

In postgis.sql ---

create table authorization_table (tname text, fid text, expires date, authid text, PRIMARY KEY (tname,fid));

--- select AuthorizationUnLock ( <authid)
--- removes the lock from the authorization_table
create or replace function AuthorizationUnLock( TEXT )
RETURNS INT
AS '
BEGIN
EXECUTE ''DELETE FROM authorization_table where authid = '' || quote_literal($1);
RETURN 0;
END;
'
LANGUAGE 'plpgsql';

--- select AuthorizationLock( text tname, text FID, date expires, text AuthID ) create or replace function AuthorizationLock (text, text, date, text)
RETURNS INT
AS '
DECLARE
tname alias for $1;
fid alias for $2;
expires alias for $3;
authid alias for $4;

BEGIN
EXECUTE ''DELETE FROM authorization_table WHERE expires < now()''; EXECUTE ''INSERT INTO authorization_table VALUES (''||quote_literal(tname) ||'',''||quote_literal(fid) ||'',''||quote_literal(expires) ||'',''||quote_literal(authid) ||'')'';
RETURN 0;
END;'
LANGUAGE 'plpgsql';

--- AuthroizationTriggerAttacher( text tname, text fidcolumn ) create or replace function AuthroizationTriggerAttacher( text, text ) returns INT
AS '
BEGIN EXECUTE '' CREATE TRIGGER authorizationlocktrigger BEFORE UPDATE OR DELETE ON '' ||$1 ||'' FOR EACH ROW EXECUTE PROCEDURE lockcheck(''|| quote_literal($2) || '') '';
RETURN 0;
END;
'
LANGUAGE 'plpgsql';

CREATE FUNCTION lockcheck() RETURNS TRIGGER AS '/data1/Refractions/Projects/PostGIS/work_dave/postgis/libpostgis.so.0.8' LANGUAGE C;

CREATE FUNCTION getTransactionID() RETURNS XID AS '/data1/Refractions/Projects/PostGIS/work_dave/postgis/libpostgis.so.0.8','getTransactionID' LANGUAGE C;

CREATE OR REPLACE FUNCTION haveAuthorization(TEXT) RETURNS BOOLEAN AS
'
DECLARE
lockid alias for $1;
okay boolean;
myrec record;
BEGIN
-- check to see if table exists
-- if not, CREATE TEMP TABLE mylock (transid xid, lockcode text)

okay := ''f'';
FOR myrec IN SELECT * FROM pg_class WHERE relname = ''temp_lock_have_table'' LOOP
  okay := ''t'';
END LOOP; IF (okay <> ''t'') THEN EXECUTE ''CREATE TEMP TABLE temp_lock_have_table (transid xid, lockcode text)'';
END IF;

-- delete everything in TEMP table with xid != current xid
EXECUTE ''DELETE FROM temp_lock_have_table WHERE not(xideq(transid , getTransactionID()))'';
-- INSERT INTO mylock VALUES ( getTransactionID(), $1)
EXECUTE ''INSERT INTO temp_lock_have_table VALUES ( getTransactionID(), ''|| quote_literal(lockid) ||'')'';
RETURN true::boolean;
END;
'
LANGUAGE PLPGSQL with (isstrict);

CREATE TABLE geo_table (id int primary key,the_geom geometry, name text);
select AuthroizationTriggerAttacher('geo_table', 'id');

insert into geo_table values (1, 'POINT(0 0)', 'dave');
insert into geo_table values (2, 'POINT(1 0)', 'jody');
insert into geo_table values (3, 'POINT(2 0)', 'brent');
insert into geo_table values (4, 'POINT(3 0)', 'justin');

-- this will update one row
BEGIN;
select authorizationlock('geo_table','2','2004-01-01','XX22XX'); -- lock 'jody'
select haveAuthorization('XX22XX');
update geo_table set name = 'Jody' where id = 2;
END;

-- this will try to update one row (and throw an error)
BEGIN;
select authorizationlock('geo_table','2','2004-01-01','XX22XX'); -- lock 'jody'
--- select haveAuthorization('XX22XX');
update geo_table set name = 'Jody' where id = 2;
END;

strk@anonymised.com 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

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@anonymised.com 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

strk@anonymised.com wrote:

Sorry if I insist on this, but postgis has never had the locking support in its releases (correct me if I'm wrong).

This is apparently true - I had thought it was already included.

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.

Not quite true - we are after a specific locking strategy that is specific to features.
This is why rows are locked by "fid". If we present this as a general row-level
multi-session locking scheme others will be tempted to modify it away from something
that meets our needs. Many of our needs don't make sense from a database perspective
(for example it would be nice as a database to return a "authorization token" or failure in
response to a lock request. Unfortuantly this would not work for wfs locking - as the same
authorization token needs to be used across multiple database from different vendors).

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.

Fair enough.

What do people think about this ?
(I'm just trying to keep postgis clean)

An admirable goal - thanks for your thought.
Jody

Quoting Jody Garnett <jgarnett@anonymised.com>:

strk@anonymised.com wrote:

>Sorry if I insist on this, but postgis has never had
>the locking support in its releases (correct me if I'm wrong).
>
>
This is apparently true - I had thought it was already included.

Yeah, I don't think I ever had GeoServer working with PostGIS locking -
always just used the in memory ones.

>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.
>
>
Fair enough.

>What do people think about this ?
>(I'm just trying to keep postgis clean)

Yeah, I like this a lot. I was always a little weirded out by putting
stuff that only geoserver had a use for in postgis (though
theoretically any other WFS implementing locking would need it). If
users want locking in postgis then they can do a little extra work.
Indeed we could maybe even have an 'enable native locking' function
that would connect to the db and run the sql script.

Chris

>
>
An admirable goal - thanks for your thought.

Jody

-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon
2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest
Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.
Register
by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

On Wed, Mar 23, 2005 at 06:14:52PM -0800, Jody Garnett wrote:

strk@anonymised.com wrote:

...

>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.
>
>
Not quite true - we are after a specific locking strategy that is
specific to features.
This is why rows are locked by "fid". If we present this as a general
row-level
multi-session locking scheme others will be tempted to modify it away
from something
that meets our needs. Many of our needs don't make sense from a database
perspective
(for example it would be nice as a database to return a "authorization
token" or failure in
response to a lock request. Unfortuantly this would not work for wfs
locking - as the same
authorization token needs to be used across multiple database from
different vendors).

Point taken. What is requested here is a WFS-specific locking
mechanism. Current API is not correct then.

First question is: what makes up a feature ?

In a table like:

  gid serial
  data1 text
  geom1 geometry
  geom2 geometry

Do we have 2 features or only one ? Where is this information kept ?
In the first case, do the features share the data1 attribute ?

What does geoserver use as a Feature id ?

--strk;

strk@anonymised.com wrote:

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.
     

This is why rows are locked by "fid". If we present this as a general row-level multi-session locking scheme others will be tempted to modify it away from something that meets our needs. Many of our needs don't make sense from a database perspective
   

Point taken. What is requested here is a WFS-specific locking mechanism. Current API is not correct then.

I would rather think of it as a Feature specific locking mechanism. I thought the current API is correct, the above is an argument for this being a Postgis thing (postgis lets me store features into tables).

First question is: what makes up a feature ?

See the OGC feature specification.

In a table like:

gid serial
data1 text
geom1 geometry
geom2 geometry

Do we have 2 features or only one ?

One feature (with a "table.serial" for the FeatureID string), it has three attributes: data1, geom1 and geom2. It is even money if gid is visiable as an attribute or not. Geotools says no, GeoAPI and Degree says yes. (even money = I have heard the experts and they did not agree).

Where is this information kept ?

The database?

What does geoserver use as a Feature id ?

It is not just geoserver, a feature id is part of what *defines* a feature in the OGC standard world. There specifications talk about having Features with *no* geometry (but they still have a FID).

Jody

[ what about keeping the discussion in a single mailing list ? ]

On Thu, Mar 24, 2005 at 03:57:21AM -0800, Jody Garnett wrote:
...

One feature (with a "table.serial" for the FeatureID string), it has
three attributes: data1, geom1 and geom2. It is even money if gid is
visiable as an attribute or not. Geotools says no, GeoAPI and Degree
says yes. (even money = I have heard the experts and they did not agree).

...

It is not just geoserver, a feature id is part of what *defines* a
feature in the OGC standard world. There specifications talk about
having Features with *no* geometry (but they still have a FID).

I've read the Simple Feature Specification for SQL spec again
and it does NOT talk about a required Feature id to be present.

Actually postgis currently works fine w/out knowledge of them,
and usually users choose their way of expressing it
(shp2pgsql adds a gid, but nothing prevents you from using other
or no columns for it).

Anyway... I've packaged both C library and .sql files so you can
have a look at them. Build scripts are really rude, but can be
a start. As far as postgis or geotools or geoserver or whoever
has WFS in mind will maintain it, the code (IMHO) can as well be
of general use.

Package attached.

--strk;

(attachments)

WFS_locks.tgz (3.98 KB)

>First question is: what makes up a feature ?
>
>
See the OGC feature specification.

>In a table like:
>
> gid serial
> data1 text
> geom1 geometry
> geom2 geometry
>
>Do we have 2 features or only one ?
>
One feature (with a "table.serial" for the FeatureID string), it has
three attributes: data1, geom1 and geom2. It is even money if gid is
visiable as an attribute or not. Geotools says no, GeoAPI and Degree
says yes. (even money = I have heard the experts and they did not
agree).

You know, I think we should actually change this, and allow users to
specify if they want the fid visible as an attribute or not. I had a
suggestion from a user, and I think even a fix, and it sounds like a
good idea to me.

>Where is this information kept ?
>
>
The database?

>What does geoserver use as a Feature id ?
>
>
It is not just geoserver, a feature id is part of what *defines* a
feature in the OGC standard world. There specifications talk about
having Features with *no* geometry (but they still have a FID).

FID stuff is super annoying, since all they say is that you have to have
one, it has to be unique, and has to be persistant. Different
implementors do different things. Leveraging primary keys when
available to me is the most sensible solution. But basically we try to
deal with whatever the user may have set up in reasonable default ways,
and then allow users control as much as possible in setting it up other
ways. The oid used to work great as the fid, since it was hidden for
the most part. Put Paul said it was going away in the future or
something.

Chris

Jody

-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon
2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest
Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.
Register
by 3/29 & save $300
http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/