great, thanks for the info. On Wed, Jun 17, 2015 at 3:43 PM, Torben Barsballe < tbarsba...@boundlessgeo.com> wrote:
> 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 >> >> > -- * 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
