[Geoserver-devel] WFS insert transaction events

GeoServer GeoServer Developer
1

Hey all,

I'm looking for a bit of advise on how to get what I need out from the
insert transaction events, which is no more than a transaction
listener/plugin to know the actual inserted features or at least its
feature ids.

Right now it looks like there's no way for a transaction listener to get
a handle to the inserted feature ids nor de actual inserted features, as
InsertElementHandler doesn't provide neither, nor Transaction does for
the TransactionPlugins?

As for InsertElementHandler, it wouldn't even help if it issued a
POST_INSERT event as is, since the source feature collection wouldn't
have the newly generated fids.
May be the easiest way forward would be for the
TransactionPlugin.afterTransaction(TransactionType request, boolean
committed) method to also receive the TransactionResponseType response
so implementations can get to the InsertResultsType and grab the list of
inserted feature ids?

And in the process may be also remove the
TransactionEventType.POST_INSERT constant as it looks it's not used
anywhere and it's confusing for it to be there?

TIA,
Gabriel
--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

2

On Mon, May 9, 2011 at 5:25 PM, Gabriel Roldán <groldan@anonymised.com> wrote:

Hey all,

I'm looking for a bit of advise on how to get what I need out from the
insert transaction events, which is no more than a transaction
listener/plugin to know the actual inserted features or at least its
feature ids.

Right now it looks like there's no way for a transaction listener to get
a handle to the inserted feature ids nor de actual inserted features, as
InsertElementHandler doesn't provide neither, nor Transaction does for
the TransactionPlugins?

As for InsertElementHandler, it wouldn't even help if it issued a
POST_INSERT event as is, since the source feature collection wouldn't
have the newly generated fids.
May be the easiest way forward would be for the
TransactionPlugin.afterTransaction(TransactionType request, boolean
committed) method to also receive the TransactionResponseType response
so implementations can get to the InsertResultsType and grab the list of
inserted feature ids?

Yep, sounds like a reasonable solution. Mind though, not all stores will
give you back a valid id. If you do transactions on shapefiles _I believe_
you won't get back a valid id (might be wrong, but I remember those
giving back ids like "new0", "new1" and so on).

And in the process may be also remove the
TransactionEventType.POST_INSERT constant as it looks it's not used
anywhere and it's confusing for it to be there?

POST_INSERT event is fired by WFSV rollback operation, so please
don't remove it. As for the recent WPS build breakage due to changes in the
WFS SHAPE-ZIP it would be good if you could load all of the projects
in the release
when making code analysis, and do a build with -Prelease before committing.
Extension modules are less important, yet they still are in the build and the
release so we should take them into account when making changes.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

3

> May be the easiest way forward would be for the
> TransactionPlugin.afterTransaction(TransactionType request, boolean
> committed) method to also receive the TransactionResponseType response
> so implementations can get to the InsertResultsType and grab the list of
> inserted feature ids?

Yep, sounds like a reasonable solution. Mind though, not all stores will
give you back a valid id. If you do transactions on shapefiles _I believe_
you won't get back a valid id (might be wrong, but I remember those
giving back ids like "new0", "new1" and so on).

yup, that's what shapefile does... for my use case I'm going to have to
limit to stores that provide steady fids anyways.
As a side note, iirc, arcview used to use a special shapefile field for
ids, and I wonder if we could at some point make it so that what
attribute is the fid is configurable, as well as whether it's user
provided or system generated (uuid would be the easier, some kind of
numeric sequence a bit harder).

> And in the process may be also remove the
> TransactionEventType.POST_INSERT constant as it looks it's not used
> anywhere and it's confusing for it to be there?

POST_INSERT event is fired by WFSV rollback operation, so please
don't remove it. As for the recent WPS build breakage due to changes in the
WFS SHAPE-ZIP it would be good if you could load all of the projects
in the release
when making code analysis, and do a build with -Prelease before committing.
Extension modules are less important, yet they still are in the build and the
release so we should take them into account when making changes.

of course.

Cheers,
Gabriel

Cheers
Andrea

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

4

aside: I commented at <http://jira.codehaus.org/browse/GEOS-4543&gt; on the
need for TransactionEvent to hold a reference to the originating
TransactionType.

Please let me know if that sounds good too. Otherwise I'd need to
implement something else like a thread local cache or so that I'd rather
avoid.

TIA,
Gabriel
On Tue, 2011-05-10 at 11:39 -0300, Gabriel Roldán wrote:

> > May be the easiest way forward would be for the
> > TransactionPlugin.afterTransaction(TransactionType request, boolean
> > committed) method to also receive the TransactionResponseType response
> > so implementations can get to the InsertResultsType and grab the list of
> > inserted feature ids?
>
> Yep, sounds like a reasonable solution. Mind though, not all stores will
> give you back a valid id. If you do transactions on shapefiles _I believe_
> you won't get back a valid id (might be wrong, but I remember those
> giving back ids like "new0", "new1" and so on).
yup, that's what shapefile does... for my use case I'm going to have to
limit to stores that provide steady fids anyways.
As a side note, iirc, arcview used to use a special shapefile field for
ids, and I wonder if we could at some point make it so that what
attribute is the fid is configurable, as well as whether it's user
provided or system generated (uuid would be the easier, some kind of
numeric sequence a bit harder).
>
> > And in the process may be also remove the
> > TransactionEventType.POST_INSERT constant as it looks it's not used
> > anywhere and it's confusing for it to be there?
>
> POST_INSERT event is fired by WFSV rollback operation, so please
> don't remove it. As for the recent WPS build breakage due to changes in the
> WFS SHAPE-ZIP it would be good if you could load all of the projects
> in the release
> when making code analysis, and do a build with -Prelease before committing.
> Extension modules are less important, yet they still are in the build and the
> release so we should take them into account when making changes.
of course.

Cheers,
Gabriel
>
> Cheers
> Andrea
>
>

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers