[Geoserver-devel] VersionedFeatureCollection improvements

Hi,
so I've been working on adding the creation attributes to the
versioned feature collection. The result is that the versioned
features have now 8 extra attributes, that is version, author,
date and message relating both to the feature creation and the
last update.

The result looks like the following:

<topp:archsites fid="archsites.1">
   <topp:creationVersion>1</topp:creationVersion>
   <topp:creationDate>2007-12-21T11:41:47.64</topp:creationDate>
   <topp:creationMessage>
     Version enabling archsites
   </topp:creationMessage>
   <topp:lastUpdateVersion>7</topp:lastUpdateVersion>
   <topp:lastUpdatedBy>anonymous</topp:lastUpdatedBy>
   <topp:lastUpdateDate>2007-12-21T12:10:34.328</topp:lastUpdateDate>
   <topp:lastUpdateMessage>
     Updating Signature rock label
   </topp:lastUpdateMessage>
   <topp:cat>1</topp:cat>
   <topp:str1>Signature Rock, updated</topp:str1>
   <topp:the_geom>
     <gml:Point
       srsName="http://www.opengis.net/gml/srs/epsg.xml#26713&quot;&gt;
       <gml:coordinates xmlns:gml="http://www.opengis.net/gml&quot;
         decimal="." cs="," ts=" ">
         593493,4914730
       </gml:coordinates>
     </gml:Point>
   </topp:the_geom>
</topp:archsites>

the above misses topp:createdBy because the creation refers to
the actual process of version enabling the feature type,
that was carried out automatically.

Sebastian, is this what you needed for your project?
If so, ask the latest geoserver build. Unfortunately to
support the above I also needed to change the database schema,
so you have two alternatives:
* drop and recreate the database from scratch, and let the
   datastore version enabled it (or create another one
   so that you can go back to the old one in case something
   does not work).
* alter the db.

The second alternative requires the following. Say you have
the "river" table that has been version enabled by the
old datastore. You have to run the following:

alter table river add column created bigint references changesets(revision);
update river
set created = (
    select min(r2.revision)
    from river r2
    where r2.fid = river.fid
);
alter table river alter column created set not null;

If the river_vfc_view is around you also have to drop it:

drop view river_vfc_view;

This has to be done for every table that has been
version enabled.

Let me know how this works for you. Unfortunately I still
do not have unit testing set up so I could only do some
interactive tests.

Cheers
Andrea

Thanks Andrea. That’s a big help.

On Dec 21, 2007 6:44 AM, Andrea Aime <aaime@anonymised.com> wrote:

Hi,
so I’ve been working on adding the creation attributes to the
versioned feature collection. The result is that the versioned
features have now 8 extra attributes, that is version, author,
date and message relating both to the feature creation and the
last update.

The result looks like the following:

<topp:archsites fid=“archsites.1”>
topp:creationVersion1</topp:creationVersion>
topp:creationDate2007-12-21T11:41: 47.64</topp:creationDate>
topp:creationMessage
Version enabling archsites
</topp:creationMessage>
topp:lastUpdateVersion7</topp:lastUpdateVersion>
topp:lastUpdatedByanonymous</topp:lastUpdatedBy>
topp:lastUpdateDate2007-12-21T12:10:34.328</topp:lastUpdateDate>
topp:lastUpdateMessage
Updating Signature rock label
</topp:lastUpdateMessage>
topp:cat1</topp:cat>
topp:str1Signature Rock, updated</topp:str1>
topp:the_geom
<gml:Point
srsName=“http://www.opengis.net/gml/srs/epsg.xml#26713 “>
<gml:coordinates xmlns:gml=“http://www.opengis.net/gml
decimal=”.” cs=“,” ts=" ">
593493,4914730
</gml:coordinates>
</gml:Point>
</topp:the_geom>
</topp:archsites>

the above misses topp:createdBy because the creation refers to
the actual process of version enabling the feature type,
that was carried out automatically.

Sebastian, is this what you needed for your project?
If so, ask the latest geoserver build. Unfortunately to
support the above I also needed to change the database schema,
so you have two alternatives:

  • drop and recreate the database from scratch, and let the
    datastore version enabled it (or create another one
    so that you can go back to the old one in case something
    does not work).
  • alter the db.

The second alternative requires the following. Say you have
the “river” table that has been version enabled by the
old datastore. You have to run the following:

alter table river add column created bigint references changesets(revision);
update river
set created = (
select min(r2.revision)
from river r2
where r2.fid = river.fid
);
alter table river alter column created set not null;

If the river_vfc_view is around you also have to drop it:

drop view river_vfc_view;

This has to be done for every table that has been
version enabled.

Let me know how this works for you. Unfortunately I still
do not have unit testing set up so I could only do some
interactive tests.

Cheers
Andrea

Hi Andrea,

may be the following concern is irrelevant for the state of the wfsv, but just
caught my attention and am wondering if it could be of some help.

Correct me if I'm wrong, but, in my mind, all versioned features inherit from
some sort of AbstractVersionedFeature?
So, AbstractVersionedFeature should belong to a namespace, say
http://www.geoserver.org/wfsv, and say its bound to the wfsv prefix.
So, it wold make sense if the versioning properties of a versioned feature are
bound to the wfsv namespace? like in:
<topp:archsites fid="archsites.1">
    <wfsv:creationVersion>1</topp:creationVersion>
    <wfsv:creationDate>2007-12-21T11:41:47.64</topp:creationDate>
    ...
    <wfsv:cat>1</topp:cat>
    <topp:str1>Signature Rock, updated</topp:str1>
    ....
</topp:archsites>

?
Gabriel

On Friday 21 December 2007 12:44:18 pm Andrea Aime wrote:

Hi,
so I've been working on adding the creation attributes to the
versioned feature collection. The result is that the versioned
features have now 8 extra attributes, that is version, author,
date and message relating both to the feature creation and the
last update.

The result looks like the following:

<topp:archsites fid="archsites.1">
   <topp:creationVersion>1</topp:creationVersion>
   <topp:creationDate>2007-12-21T11:41:47.64</topp:creationDate>
   <topp:creationMessage>
     Version enabling archsites
   </topp:creationMessage>
   <topp:lastUpdateVersion>7</topp:lastUpdateVersion>
   <topp:lastUpdatedBy>anonymous</topp:lastUpdatedBy>
   <topp:lastUpdateDate>2007-12-21T12:10:34.328</topp:lastUpdateDate>
   <topp:lastUpdateMessage>
     Updating Signature rock label
   </topp:lastUpdateMessage>
   <topp:cat>1</topp:cat>
   <topp:str1>Signature Rock, updated</topp:str1>
   <topp:the_geom>
     <gml:Point
       srsName="http://www.opengis.net/gml/srs/epsg.xml#26713&quot;&gt;
       <gml:coordinates xmlns:gml="http://www.opengis.net/gml&quot;
         decimal="." cs="," ts=" ">
         593493,4914730
       </gml:coordinates>
     </gml:Point>
   </topp:the_geom>
</topp:archsites>

the above misses topp:createdBy because the creation refers to
the actual process of version enabling the feature type,
that was carried out automatically.

Sebastian, is this what you needed for your project?
If so, ask the latest geoserver build. Unfortunately to
support the above I also needed to change the database schema,
so you have two alternatives:
* drop and recreate the database from scratch, and let the
   datastore version enabled it (or create another one
   so that you can go back to the old one in case something
   does not work).
* alter the db.

The second alternative requires the following. Say you have
the "river" table that has been version enabled by the
old datastore. You have to run the following:

alter table river add column created bigint references
changesets(revision); update river
set created = (
    select min(r2.revision)
    from river r2
    where r2.fid = river.fid
);
alter table river alter column created set not null;

If the river_vfc_view is around you also have to drop it:

drop view river_vfc_view;

This has to be done for every table that has been
version enabled.

Let me know how this works for you. Unfortunately I still
do not have unit testing set up so I could only do some
interactive tests.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4045,476ba72e216631804284693!

Gabriel Roldán ha scritto:

Hi Andrea,

may be the following concern is irrelevant for the state of the wfsv, but just caught my attention and am wondering if it could be of some help.

Correct me if I'm wrong, but, in my mind, all versioned features inherit from some sort of AbstractVersionedFeature?
So, AbstractVersionedFeature should belong to a namespace, say http://www.geoserver.org/wfsv, and say its bound to the wfsv prefix.

Indeed, that's what's happening now already. In wfsv.xsd you find:

<xsd:complexType name="AbstractVersionedFeatureType" abstract="true">
     <xsd:complexContent>
       <xsd:extension base="gml:AbstractFeatureType">
         <xsd:sequence>
           <xsd:element name="creationVersion" type="xsd:string" minOccurs="1"/>
           <xsd:element name="createdBy" type="xsd:string" minOccurs="0"/>
           <xsd:element name="creationDate" type="xsd:dateTime" minOccurs="1"/>
           <xsd:element name="creationMessage" type="xsd:string" minOccurs="0"/>
           <xsd:element name="lastUpdateVersion" type="xsd:string" minOccurs="1"/>
           <xsd:element name="lastUpdatedBy" type="xsd:string" minOccurs="0"/>
           <xsd:element name="lastUpdateDate" type="xsd:dateTime" minOccurs="1"/>
           <xsd:element name="lastUpdateMessage" type="xsd:string" minOccurs="0"/>
         </xsd:sequence>
       </xsd:extension>
     </xsd:complexContent>
   </xsd:complexType>

So, it wold make sense if the versioning properties of a versioned feature are bound to the wfsv namespace? like in:
<topp:archsites fid="archsites.1">
    <wfsv:creationVersion>1</topp:creationVersion>
    <wfsv:creationDate>2007-12-21T11:41:47.64</topp:creationDate>

Woops, you're right, the prefix is wrong! Opened a jira issue
for this one:
http://jira.codehaus.org/browse/GEOS-1637
Cheers
Andrea

I know I said this before but I do think that it would be much simpler
if all the "versioning" stuff was just thrown into the normal wfs
namespace. As our last experiment trying to add
VersionedFeatureCollection showed it would definitely be simpler from an
implementation standpoint. It is also one less level of "Schema" import
in which there is already too much with ogc schemas, so i think it would
make it simpler in general.

Perhaps something to keep in mind. There is already a client that
depends on teh wfsv namesace then changing this later might be tough.

My 2c.

-Justin

Andrea Aime wrote:

Gabriel Roldán ha scritto:

Hi Andrea,

may be the following concern is irrelevant for the state of the wfsv, but just
caught my attention and am wondering if it could be of some help.

Correct me if I'm wrong, but, in my mind, all versioned features inherit from
some sort of AbstractVersionedFeature?
So, AbstractVersionedFeature should belong to a namespace, say
http://www.geoserver.org/wfsv, and say its bound to the wfsv prefix.

Indeed, that's what's happening now already. In wfsv.xsd you find:

<xsd:complexType name="AbstractVersionedFeatureType" abstract="true">
     <xsd:complexContent>
       <xsd:extension base="gml:AbstractFeatureType">
         <xsd:sequence>
           <xsd:element name="creationVersion" type="xsd:string"
minOccurs="1"/>
           <xsd:element name="createdBy" type="xsd:string" minOccurs="0"/>
           <xsd:element name="creationDate" type="xsd:dateTime"
minOccurs="1"/>
           <xsd:element name="creationMessage" type="xsd:string"
minOccurs="0"/>
           <xsd:element name="lastUpdateVersion" type="xsd:string"
minOccurs="1"/>
           <xsd:element name="lastUpdatedBy" type="xsd:string"
minOccurs="0"/>
           <xsd:element name="lastUpdateDate" type="xsd:dateTime"
minOccurs="1"/>
           <xsd:element name="lastUpdateMessage" type="xsd:string"
minOccurs="0"/>
         </xsd:sequence>
       </xsd:extension>
     </xsd:complexContent>
   </xsd:complexType>

So, it wold make sense if the versioning properties of a versioned feature are
bound to the wfsv namespace? like in:
<topp:archsites fid="archsites.1">
    <wfsv:creationVersion>1</topp:creationVersion>
    <wfsv:creationDate>2007-12-21T11:41:47.64</topp:creationDate>

Woops, you're right, the prefix is wrong! Opened a jira issue
for this one:
http://jira.codehaus.org/browse/GEOS-1637
Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,476be65e285022092453641!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Justin Deoliveira ha scritto:

I know I said this before but I do think that it would be much simpler
if all the "versioning" stuff was just thrown into the normal wfs
namespace. As our last experiment trying to add
VersionedFeatureCollection showed it would definitely be simpler from an
implementation standpoint. It is also one less level of "Schema" import
in which there is already too much with ogc schemas, so i think it would
make it simpler in general.

Perhaps something to keep in mind. There is already a client that
depends on teh wfsv namesace then changing this later might be tough.

I agree with you, see my other mail about difficulties in implemneting
the versioned feature collection thing, it said:

"Finally, I noticed that people get tangled up with
namespaces, to make up a GetVersionedFeature
request one has to play with wfsv, wfs, ogc
and gml...hmmm... too many.
Justin was suggesting to move the versioning
WFS stuff back to the WFS namespace, similarly to how
transactional is already and extension on top of
basic. Sounds reasonable, and would simplify
writing up wfsv requests."

I was just waiting for a get go from the boss :wink:
Cheers
Andrea