Hi all,
I got an error when sending a WFS GetFeature to GeoServer 2.4.1
org.geoserver.wfs.WFSException: Illegal property name: income_grp
at org.geoserver.wfs.GetFeature$1.visit(GetFeature.java:1112)
I am querying a layer featuretype that was firstly published without that field. Then I removed it from GeoServer, added some fields in the PostGIS table and published it again, started form layers>add resource.
I had to press the reload feature type button in the layer configuration page.
Is it normal?
Thank you for your suggestions
Cheers,
Stefano
41.95581N 12.52854E
http://www.linkedin.com/in/stefanoiacovella
http://twitter.com/#!/Iacovellas
On Fri, Oct 25, 2013 at 5:31 PM, Stefano Iacovella <
stefano.iacovella@anonymised.com> wrote:
Hi all,
I got an error when sending a WFS GetFeature to GeoServer 2.4.1
org.geoserver.wfs.WFSException: Illegal property name: income_grp
at org.geoserver.wfs.GetFeature$1.visit(GetFeature.java:1112)
I am querying a layer featuretype that was firstly published without that
field. Then I removed it from GeoServer, added some fields in the PostGIS
table and published it again, started form layers>add resource.
I had to press the reload feature type button in the layer configuration
page.
Is it normal?
It is. The data store keeps caches of the feature types too, you should at
least force a reset of the data
stores (so not a full reload, but a reset)
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
On Fri, Oct 25, 2013 at 5:46 PM, Stefano Iacovella <
stefano.iacovella@anonymised.com> wrote:
2013/10/25 Andrea Aime <andrea.aime@anonymised.com>
It is. The data store keeps caches of the feature types too, you should
at least force a reset of the data
stores (so not a full reload, but a reset)
Thank you Andrea,
I thought that removing the feature type should also invalidate the cache.
It invalidates GeoServer one. The one managed by the stores is private, no
way to reach it and
drop it. Different stores do it in a different way, some do not have it at
all, but for JDBC ones
it is crucial, because of the high cost in figuring out the feature type
structure (many queries
to the DBMS are normally required)
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
2013/10/25 Andrea Aime <andrea.aime@anonymised.com>
It invalidates GeoServer one. The one managed by the stores is private, no
way to reach it and
drop it. Different stores do it in a different way, some do not have it at
all, but for JDBC ones
it is crucial, because of the high cost in figuring out the feature type
structure (many queries
to the DBMS are normally required)
So when I am removing the featuretype the store caches information about
its structure just in case I would create it again in the near future, is
it right?
And is it this behaviour not ovveridable by the calling method?
Or is it more wise a conservative approach and avoiding to destroy
information that may turn useful?
Thank you very much for your time and the extremely clear explanation, as
usual.
Cheers,
Stefano
---------------------------------------------------
41.95581N 12.52854E
http://www.linkedin.com/in/stefanoiacovella
http://twitter.com/#!/Iacovellas
On Fri, Oct 25, 2013 at 6:03 PM, Stefano Iacovella <
stefano.iacovella@anonymised.com> wrote:
2013/10/25 Andrea Aime <andrea.aime@anonymised.com>
It invalidates GeoServer one. The one managed by the stores is private,
no way to reach it and
drop it. Different stores do it in a different way, some do not have it
at all, but for JDBC ones
it is crucial, because of the high cost in figuring out the feature type
structure (many queries
to the DBMS are normally required)
So when I am removing the featuretype the store caches information about
its structure just in case I would create it again in the near future, is
it right?
Going to talk about the JDBC stores (spatial databases), since any store
handles this in a different way (as said, some do not
cache the structure at all).
The JDBC store caches the feature type the first time the structure of a
feature type is needed. There is no notion of "near feature"
in this case, the cached information is stored permanently
And is it this behaviour not ovveridable by the calling method?
No. But even if there was a specific way for the JDBC stores, there is
another issue: GeoServer has no idea what
kind of store it's talking to.
So if we wanted to add a method, we would have to add it to the
DataAccess/DataStore interfaces, so that GeoServer
can drop eventual caches without having to know what kind of data backend
it's talking to.
Which, in turn, would require a proposal at the GeoTools level, and some
work in each and every store implemented
so far.
So possible, and could be useful too, but not exactly a couple of hours hack
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------