Some data import tools, nothing inside of the geoserver code base.
On Thu, Apr 19, 2012 at 10:53 AM, David Winslow <[email protected]>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
> <[email protected]>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 <[email protected]>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
>>> [email protected]
>>> 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.
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
