On Fri, Apr 25, 2014 at 4:21 PM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Fri, Apr 25, 2014 at 2:47 PM, Sampo Savolainen <
> sampo.savolai...@spatineo.com> wrote:
>
>> Generalizing this is definitely one way to go. I'm a bit wary of starting
>>> doing that, especially since from the looks of it, the SQL view
>>> implementation looks a bit iffy. See the third line you quoted:
>>>
>> if(dataStore instanceof JDBCDataStore && info.getMetadata() != null &&
>>
>> info.getMetadata().containsKey(FeatureTypeInfo.JDBC_VIRTUAL_TABLE)) {
>> ...
>>
>> The dataStore object might already be wrapped! This means this code does
>> not work in every case.
>>
>
> 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()
> 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.
> 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.
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.
However, like you pointed out, it doesn't cover other cases (than queries)
where interaction between GS and GT requires the GT side of things to have
the configuration.
Sampo
--
Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolai...@spatineo.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc
This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.
------------------------------------------------------------------------------
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
