Hi all,
I’m looking into some REST API improvements and I see there are a few places where unique names should be autogenerated - in the data upload handling we create a new layer and need to ensure it doesn’t have a name clash with other layers in the same workspace; I’d also like to have an option for the data upload to generate a new style, which is also subject to naming conflicts. I was looking at the code in DataStoreFileResource and I see that it just tries all the possible suffixes from 1 to 10 and gives up if that doesn’t work (see line 393 and on for the details.) Might be nice for it to try a bit harder (maybe fetch all layers with the requested name as a prefix and do something smart with the results?)
It also seems like this would be a useful thing to abstract out - I’m thinking of adding a method like
class CatalogBuilder {
public String uniqueName(WorkspaceInfo workspace, String requestedName, Class<? extends ResourceInfo> resourceType)
}
which would handle that logic in a more centralized location. Any thoughts?
This is relevant to at least these tickets:
http://jira.codehaus.org/browse/GEOS-2635
https://jira.codehaus.org/browse/GEOS-5057
–
David Winslow
OpenGeo - http://opengeo.org/
+1. I have actually needed this functionality on other projects and had to roll out a method to do exactly this.
On Wed, Apr 18, 2012 at 6:36 PM, David Winslow <dwinslow@anonymised.com> wrote:
Hi all,
I’m looking into some REST API improvements and I see there are a few places where unique names should be autogenerated - in the data upload handling we create a new layer and need to ensure it doesn’t have a name clash with other layers in the same workspace; I’d also like to have an option for the data upload to generate a new style, which is also subject to naming conflicts. I was looking at the code in DataStoreFileResource and I see that it just tries all the possible suffixes from 1 to 10 and gives up if that doesn’t work (see line 393 and on for the details.) Might be nice for it to try a bit harder (maybe fetch all layers with the requested name as a prefix and do something smart with the results?)
It also seems like this would be a useful thing to abstract out - I’m thinking of adding a method like
class CatalogBuilder {
public String uniqueName(WorkspaceInfo workspace, String requestedName, Class<? extends ResourceInfo> resourceType)
}
which would handle that logic in a more centralized location. Any thoughts?
This is relevant to at least these tickets:
http://jira.codehaus.org/browse/GEOS-2635
https://jira.codehaus.org/browse/GEOS-5057
–
David Winslow
OpenGeo - http://opengeo.org/
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Which projects? Are there other places in the GeoServer code base that should be refactored to use the new API?
–
David Winslow
OpenGeo - http://opengeo.org/
On Thu, Apr 19, 2012 at 8:26 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
+1. I have actually needed this functionality on other projects and had to roll out a method to do exactly this.
On Wed, Apr 18, 2012 at 6:36 PM, David Winslow <dwinslow@anonymised.com> wrote:
Hi all,
I’m looking into some REST API improvements and I see there are a few places where unique names should be autogenerated - in the data upload handling we create a new layer and need to ensure it doesn’t have a name clash with other layers in the same workspace; I’d also like to have an option for the data upload to generate a new style, which is also subject to naming conflicts. I was looking at the code in DataStoreFileResource and I see that it just tries all the possible suffixes from 1 to 10 and gives up if that doesn’t work (see line 393 and on for the details.) Might be nice for it to try a bit harder (maybe fetch all layers with the requested name as a prefix and do something smart with the results?)
It also seems like this would be a useful thing to abstract out - I’m thinking of adding a method like
class CatalogBuilder {
public String uniqueName(WorkspaceInfo workspace, String requestedName, Class<? extends ResourceInfo> resourceType)
}
which would handle that logic in a more centralized location. Any thoughts?
This is relevant to at least these tickets:
http://jira.codehaus.org/browse/GEOS-2635
https://jira.codehaus.org/browse/GEOS-5057
–
David Winslow
OpenGeo - http://opengeo.org/
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Some data import tools, nothing inside of the geoserver code base.
On Thu, Apr 19, 2012 at 10:53 AM, David Winslow <dwinslow@anonymised.com1…> wrote:
Which projects? Are there other places in the GeoServer code base that should be refactored to use the new API?
–
David Winslow
OpenGeo - http://opengeo.org/
On Thu, Apr 19, 2012 at 8:26 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
+1. I have actually needed this functionality on other projects and had to roll out a method to do exactly this.
On Wed, Apr 18, 2012 at 6:36 PM, David Winslow <dwinslow@anonymised.com…> wrote:
Hi all,
I’m looking into some REST API improvements and I see there are a few places where unique names should be autogenerated - in the data upload handling we create a new layer and need to ensure it doesn’t have a name clash with other layers in the same workspace; I’d also like to have an option for the data upload to generate a new style, which is also subject to naming conflicts. I was looking at the code in DataStoreFileResource and I see that it just tries all the possible suffixes from 1 to 10 and gives up if that doesn’t work (see line 393 and on for the details.) Might be nice for it to try a bit harder (maybe fetch all layers with the requested name as a prefix and do something smart with the results?)
It also seems like this would be a useful thing to abstract out - I’m thinking of adding a method like
class CatalogBuilder {
public String uniqueName(WorkspaceInfo workspace, String requestedName, Class<? extends ResourceInfo> resourceType)
}
which would handle that logic in a more centralized location. Any thoughts?
This is relevant to at least these tickets:
http://jira.codehaus.org/browse/GEOS-2635
https://jira.codehaus.org/browse/GEOS-5057
–
David Winslow
OpenGeo - http://opengeo.org/
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.