Skip to content

GSIP 127

Jump to bottom
Jody Garnett edited this page Jan 30, 2015 · 17 revisions

GSIP 127 - Adapt Catalog Names

Overview

Propose the creation of a Naming class to capture the naming restrictions our different protocols operate under. This utility class can be used to translate from our internal "catalog names" into a string suitable for use with each protocol.

Proposed By

Jody

Assigned to Release

This proposal is for GeoServer 2.7.x and back ported to 2.6.x as a bug fix.

State

  • Under Discussion
  • In Progress
  • Completed
  • Rejected

Deferred

Motivation

This proposal comes out of issues reported again 2.7-beta:

  • Users have created "styles" that do not match our filename restrictions
  • WCS coverages are commonly start with a number, this is different from WFS where featureTypes are restricted to be XML safe
  • The REST API and User Interface do not consistently validate names when creating and editing
  • Updating: When introducing a new naming restriction GeoServer should be in position to migrate configuration (or at least provide warnings)
  • Clients written against the previous naming restrictions should continue to function (although perhaps with warnings)

Proposal

Introduction of a Naming utility class:

enum NameContext {
   STYLE, WORKSPACE, WMS_LAYER, WCS_COVERAGE, WFS_FEATURE_TYPE;
   
   /**
    * Recommended name, safe for use in the provided context.
    * Used to generate a default name.
    */
   Name recommended( String nativeName );

   /**
    * List of warnings, if any, for using the provided name.
    */
   List<String> validate( String name );

   /**
    * Used during catalog load to migrate invalid names.
    * Can be used as a fallback for catalog lookup to ease client migration.
    */
   Name migrate( String name );
}

Example NameContext.STYLE.migrate( "foo::bar" ) returns "foo__bar":

  • During catalog load this is used to fix up filenames and style references as required (introducing a number to prevent a name collision as needed). ** REST API clients would be expected to use the now fixed name ** WMS clients requesting the style "foo::bar" will receive a warning (the name is not valid), a catalog lookup will be attempted with the migrated name. This will easy client migration issues (while introducing the possibility of the wrong style being retrieved).

Example NameContext.STYLE.validate( "$$$" ) returns "Invalid name for WMS style".

Example NameContext.STYLE.recommended( "foo" ) used when generating an initial style name (from GUI or importer).

Example NamedContext.WORKSPACE.validate("The Past Through Tomorrow") returns ("Workspace names are limited to 15 characters", "Workspace names may not contain whitespace").

Example NamedContext.WFS.recommend( "13A" ) generates "_13A" for use as a default FeatureType name when publishing a shapefile "13A.shp".

Example NamedContext.WFS.validate( "13A" ) generates ("Invalid name for use with XML formats").

Example NamedContext.WCS.validate( "13A" ) generates an empty list (as the name is valid).

{panel} What about confusion between workspace style and a style with ":" in it?

The one report we have of this issue used "::" to seperate out "tags" for a style. The use of the migrate method above should allow them to recover.

We may need to, as a temporary measure, introduce additional catalog lookups controlled by a -D flag. {panel}

The bulk of the work will be introducing the use of this class where names are used:

Feedback

Initial feedback indicates that this issue is not isolated to workspace styles.

Jukka has noticed a number of issues around naming limitations in the REST API.

David Winslow disliked the complexity of search the catalog with a range of "fixed names". I have attempted to simplify above.

Backwards Compatibility

This fix does not effect backwards compatibility (although the configuration on disk will change the resulting catalog data structures are not modified).

This fix will introduce warnings for existing clients that have hard coded invalid style names (example "foo::bar").

Voting

Project Steering Committee:

  • Alessio Fabiani
  • Andrea Aime
  • Ben Caradoc-Davies
  • Christian Mueller
  • Gabriel Roldán
  • Jody Garnett
  • Jukka Rahkonen
  • Justin Deoliveira
  • Phil Scadden
  • Simone Giannecchini

Committers:

Links

©2020 Open Source Geospatial Foundation

Home
Proposals
Release Schedule

Clone this wiki locally