On Fri, Apr 25, 2014 at 4:16 PM, Sampo Savolainen <
sampo.savolai...@spatineo.com> wrote:
> We don't wrap stores at the ResourcePool level, if we do, it's happening
>> higher level in the security
>> wrappers. ResourcePool gets the stores from the factories directly, there
>> are no intermediaries that
>> I'm aware of, just check the getDataStore code paths.
>>
>
> When I debugged this, my dataStore was wrapped as a RetypingDataStore.
> Check DataStoreUtils.getDataAccess()
>
Ah, you're right, forgot about it, your store must be emitting invalid
names (names with : inside), something that indeed
with JDBC store is possible, but very unlikely.
I believe this could be worked by removing that wrapping and making GUI and
REST config more strict about
the names they are accepting, but I haven't checked how much work that will
be.
>
>
>> What do you think about my later suggestion that we could add the
>>> metadata as a Query hint? I'm now prototyping it so that
>>> GeoServerFeatureSource is given the metadata map, which it then injects
>>> into Queries in getFeatures(). It looks promising from my point of view.
>>>
>>
>> For it to work, the feature type must to exist already, and the wrapping
>> must not change it
>> (since query hints are provided only when accessing data, not when asking
>> for metadata).
>> I'd rather use a mechanism that is not making these assumptions, they
>> make the use
>> case pretty narrow.
>>
>
> As this would be a mechanism to provide extension specific metadata to
> configured features, it would make sense that the FeatureTypeInfo should
> exist when this mechanism is used. Also, GeoServerFeatureSource.create() is
> used only in ResourcePool.getFeatureSource() - which is definitely a case
> where the feature type exists.
>
Nope, ResourcePool.getFeatureSource creates the feature type for virtual
tables, the feature type does not exist in the store before
we call addVirtualTable.
>
>
>> I could go with it, if you can show the modification to support this case
>> are minimal.
>> I don't like it because no other store works that way, so we'd be left
>> with a special
>> case for virtual stores, plus one that is likely going to be used by
>> wfs-ng only.
>>
>
> Yeah. We don't want to add something that will only be used for wfs-ng. I
> would however argue, that the reason nobody else has yet wondered about
> this problem is because before pluggable XStreamParsersInitializers, the
> extensions were themselves in charge of configuration files and they didn't
> have to to pipe their config from pure generic GS to GT. Now that the
> pluggable mechanism makes this a possibility, I see a strong case that
> other extensions might want to opt for something like this.
>
I don't buy this, personally I don't remember anybody ever asking or
experssing interest on the subject. The way I see it, stored queries are
pretty unique to the WFS 2.0 specification. Do you know of other data
sources in the wild that limit access to the store the same way? Make me
just a single example and I'll be with you about supporting this use case.
Anyways, the mechanism I talked about will be created the day I find time
to introduce feature type restructuring via TransformFeatureSource it will
be needed (but it will be my problem, along with fixing DataStoreUtils).
>
> Here are the relevant lines of code that I've changed when trying this
> model out.
>
> Add metadata to GeoServerFeatureSources:
>
> https://github.com/sampov2/geoserver/blob/22e01d28f13d536c1fcc1657a6a8fa0716489bb8/src/main/src/main/java/org/vfny/geoserver/global/GeoServerFeatureSource.java#L104
>
> https://github.com/sampov2/geoserver/blob/22e01d28f13d536c1fcc1657a6a8fa0716489bb8/src/main/src/main/java/org/vfny/geoserver/global/GeoServerFeatureSource.java#L116
>
> https://github.com/sampov2/geoserver/blob/22e01d28f13d536c1fcc1657a6a8fa0716489bb8/src/main/src/main/java/org/vfny/geoserver/global/GeoServerFeatureSource.java#L159
>
> https://github.com/sampov2/geoserver/blob/22e01d28f13d536c1fcc1657a6a8fa0716489bb8/src/main/src/main/java/org/vfny/geoserver/global/GeoServerFeatureLocking.java#L54
>
> Inject the metadata to Query objects:
>
> https://github.com/sampov2/geoserver/blob/22e01d28f13d536c1fcc1657a6a8fa0716489bb8/src/main/src/main/java/org/vfny/geoserver/global/GeoServerFeatureSource.java#L396
>
> Grab the configuration in wfs-ng:
>
> https://github.com/sampov2/geotools/blob/258b099a5b9174d1b3eeca69a6dd98754cc4815d/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/internal/v2_0/StrictWFS_2_0_Strategy.java#L367
>
> https://github.com/sampov2/geotools/blob/258b099a5b9174d1b3eeca69a6dd98754cc4815d/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/internal/v2_0/StrictWFS_2_0_Strategy.java#L454
>
> I'd say the changes are quite contained.
>
Can we see a diff? Looking for the changes inspecting the source code is
pretty inefficient.
Cheers
Andrea
--
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
==
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
-------------------------------------------------------
------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
