That is correct Jody. Specifically, it ignores arrays when generating a schema, and ensures only integer keys are used to access arrays (assuming a pre-existing/custom schema).
Before, trying to import MongoDB data containing arrays into GeoServer would throw an exception on the import page (if there was an index for one of the fields in the array) or on the OpenLayers preview (after clicking on a feature). See https://github.com/boundlessgeo/geoserver-exts/issues/83 Torben On Wed, Jun 17, 2015 at 1:34 PM, Jody Garnett <jody.garn...@gmail.com> wrote: > I think this code change detects arrays and skips over them (does not > include them in the schema). Previously I think it just failed ... > > -- > Jody Garnett > > On 17 June 2015 at 13:30, Tom Kunicki <tom.kuni...@weather.com> wrote: > >> Sorry, didn't see this until now. >> >> What's the use case for array support? I ignored these in the original >> implementation due to the feature attribute cardinality issue (1...* not >> supported) >> >> On Tue, Jun 16, 2015 at 6:06 PM, Jody Garnett <jody.garn...@gmail.com> >> wrote: >> >>> Had a look at removing the deprecation. The FilterCapabilities >>> generates a mask based on a feature type bit mask -- which only covers >>> Filter 1.0 content (so any of the new temporal filters will not be >>> available). So the deprecation stands... >>> >>> -- >>> Jody Garnett >>> >>> On 16 June 2015 at 10:38, Jody Garnett <jody.garn...@gmail.com> wrote: >>> >>>> I see, so probably should not be deprecated then. Something to add to >>>> my "technical debt" list :( >>>> >>>> Actually hold on ... after the removal of the geotools interfaces last >>>> year these two classes FilterCapabilities >>>> and PostPreProcessFilterSplittingVisitor probably don't need to be >>>> deprecated. >>>> >>>> So two ways forward - I can imagine which one you prefer. >>>> >>>> -- >>>> Jody Garnett >>>> >>>> On 16 June 2015 at 10:35, Andrea Aime <andrea.a...@geo-solutions.it> >>>> wrote: >>>> >>>>> On Tue, Jun 16, 2015 at 6:48 PM, Jody Garnett <jody.garn...@gmail.com> >>>>> wrote: >>>>> >>>>>> Ran into a couple issues with both pull requests. >>>>>> >>>>>> Torben: >>>>>> - did not compile, was missing a field reference. >>>>>> >>>>>> Stefano: >>>>>> - the getCountInternal method should return -1 (rather than a full >>>>>> table scan). Sorry if the javadocs were not clear. >>>>>> - The instance of check to ensure LikeFilter is only encoded with >>>>>> PropertyName is only half the story, the other teaching the pre post >>>>>> filter >>>>>> visitor logic about this requirement. I have hacked up an example >>>>>> <https://github.com/geotools/geotools/commit/4728ece2de1de4c9ecb832f6aacd1df174d65367> >>>>>> (to >>>>>> show what I mean) but the code should be migrated from the >>>>>> deprecated PostPreProcessFilterSplittingVisitor >>>>>> to CapabilitiesFilterSplitter to consider this fixed. >>>>>> >>>>> >>>>> Jody, mind, all "serious" stores are using >>>>> PostPreProcessFilterSplittingVisitor still, CapabilitiesFilterSplitter is >>>>> not exactly >>>>> well tested (personally I don't trust it, mostly because it has been >>>>> written, and then not used for years, who knows what >>>>> might have happened in the meantime as the code moved around). >>>>> As far as I can tell, only the WFS stores are using >>>>> CapabilitiesFilterSplitter, which gave it very little real world test >>>>> coverage >>>>> so far... if you want to push for this class, you might want to >>>>> migrate all stores on master to use it, and see if it's actually >>>>> working first? >>>>> >>>>> Cheers >>>>> Andrea >>>>> >>>>> -- >>>>> == >>>>> GeoServer Professional Services from the experts! Visit >>>>> http://goo.gl/it488V 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 >>>>> >>>>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* >>>>> >>>>> Le informazioni contenute in questo messaggio di posta elettronica e/o >>>>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il >>>>> loro utilizzo è consentito esclusivamente al destinatario del messaggio, >>>>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo >>>>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di >>>>> darcene notizia via e-mail e di procedere alla distruzione del messaggio >>>>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, >>>>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od >>>>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai >>>>> principi dettati dal D.Lgs. 196/2003. >>>>> >>>>> >>>>> >>>>> The information in this message and/or attachments, is intended solely >>>>> for the attention and use of the named addressee(s) and may be >>>>> confidential >>>>> or proprietary in nature or covered by the provisions of privacy act >>>>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection >>>>> Code).Any use not in accord with its purpose, any disclosure, >>>>> reproduction, >>>>> copying, distribution, or either dissemination, either whole or partial, >>>>> is >>>>> strictly forbidden except previous formal approval of the named >>>>> addressee(s). If you are not the intended recipient, please contact >>>>> immediately the sender by telephone, fax or e-mail and delete the >>>>> information in this message that has been received in error. The sender >>>>> does not give any warranty or accept liability as the content, accuracy or >>>>> completeness of sent messages and accepts no responsibility for changes >>>>> made after they were sent or for other risks which arise as a result of >>>>> e-mail transmission, viruses, etc. >>>>> >>>>> ------------------------------------------------------- >>>>> >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> GeoTools-Devel mailing list >>> GeoTools-Devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> >> >> >> -- >> * Tom Kunicki* | Software Engineer >> *w:* 608 695 4251 *e:* tom.kuni...@weather.com >> >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > >
------------------------------------------------------------------------------
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
