Andre,
The reason I closed it as "not a bug" was because I knew it was done by
intentional design (not by me, but by the initial developer of wfs-ng)
for a particular purpose and therefore I did not consider it a bug. You
do make good points to criticise this choice, which does affect
backwards compatibility. I do not personally oppose your alternative
suggestion.
Regards
Niels
On 04/22/2016 07:48 PM, Andrea Aime wrote:
On Thu, Apr 21, 2016 at 7:52 PM, Jody Garnett <jody.garn...@gmail.com
<mailto:jody.garn...@gmail.com>> wrote:
> Hum... wfs-ng was supposed to be a drop-in replacement,
not having a upgrade
> path seems to be a serious issue to me.
> Where is it documented?
Quick search got us this:
https://osgeo-org.atlassian.net/browse/GEOT-4883
and we googled some more messages on it.
A backwards incompable change blocking upgrades presented as a
GeoServer requirement and resolved as "not a bug"...
Reading this issue, and I agree it is not a bug - the new
datastore is behaving as designed in order to preserve valid names
for GML generation.
Jody I believe we have a problem here, in terms of responsibilities.
Is it really the job of the stores to decide what is valid, and what
is not?
Not all usage is WFS cascading, stores are used for a number of other
cases, which might have different naming limitations.
Also from a consistency point of view, did you know that you can
create a typename like "a:b" using a postgis store?
> create table "a:b" (id serial, geom geometry(POLYGON, 4326));
CREATE TABLE
And then the datastore is happily returning a:b as the typename,
And of course we also have shapefiles, on linux a file name like
a:b.shp is also completely valid.
With you and Niels claiming that is not a bug, we have a difficult
situation, as nobody else can just jump in and make
the upgrade path easier, since according to your evaluation, we'd be
introducing a bug... (and from that same point of view,
then jdbc store and shapefile store are buggy too...).
Unless of course your position is a bit more relaxed, as in, you don't
consider that a bug, but the behavior returning the native
name is valid too.
For this specific case the old datastore would of required a
similar fix (to prevent type names being of the form
"local_namespace:remote_namespace:typename").
As far as I know GeoServer was already handling the ":" in the
name, and the admin is able to rename layers as they see fit.
Yep, there is code stripping the prefix:
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/CatalogBuilder.java#L1212
GeoServer may have work arounds, but I do not mind if the new
DataStore is taking more care to produce consistent type names.
See Mark's situation though. I'm also aware of other situations like
this one that will be broken by an upgrade (systems configured
to work against well known type names in remote servers).
Mind, I checked, GeoServer is not affected, because internally we have
this little thing that hides from GeoServer the columns and
guess what, replaces them with underscores. See here:
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/vfny/geoserver/util/DataStoreUtils.java#L74
and then the retyper does this:
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/feature/retype/RetypingDataStore.java#L252
So luckily for GeoServer even if the store did change its behavior,
nothing changed config wise (we end up seeing a_b as the native
type name regardless of whether the store returns a:b or a_b because
of the above wrapper).
Given this, I'd still make it possible for GeoTools users to upgrade
from wfs to wfs-ng without this much hassle by exposing the
actual native type name.
If the worry is about valid type names for GML, I'm more than happy to
contribute a little utility wrapping store based on the GeoServer one
that does the same thing as RetypingDataStore, but centralized in one
place, and optional, only for those that actually need to do GML encoding.
A DataUtilities.makeGmlCompatible(DataStore) -> DataStore of sorts.
Cheers
Andrea
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate.
Il loro utilizzo è consentito esclusivamente al destinatario del
messaggio, per le finalità indicate nel messaggio stesso. Qualora
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
cortesemente di darcene notizia via e-mail e di procedere alla
distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
Conservare il messaggio stesso, divulgarlo anche in parte,
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
diverse, costituisce comportamento contrario ai principi dettati dal
D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely
for the attention and use of the named addressee(s) and may be
confidential or proprietary in nature or covered by the provisions of
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
Data Protection Code).Any use not in accord with its purpose, any
disclosure, reproduction, copying, distribution, or either
dissemination, either whole or partial, is strictly forbidden except
previous formal approval of the named addressee(s). If you are not the
intended recipient, please contact immediately the sender by
telephone, fax or e-mail and delete the information in this message
that has been received in error. The sender does not give any warranty
or accept liability as the content, accuracy or completeness of sent
messages and accepts no responsibility for changes made after they
were sent or for other risks which arise as a result of e-mail
transmission, viruses, etc.
-------------------------------------------------------
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel