I'm reading this thread and scratching my head... an entirely different store to change the behavior regarding dates? Can't it be a store parameter leading to the creation of a strategy object, instantiated from two different classes depending on the desired behavior, and used by a single datastore implementation?
Also please remember that while Elasticgeo is a community module, last I checked it had a maintainer (cc'ed) so first of all we should check with him (unless I "missed a memo" and the store is indeed drifting alone with no one to care for it anymore) Cheers Andrea On Fri, Jun 26, 2020 at 8:49 PM Jody Garnett <jody.garn...@gmail.com> wrote: > Travis: > > You are in charge and this is a community module. > > You can have more than one datastore implementation in a single jar (the > shapefile shipped with distinct "indexed" datastore for a while). Why not > make a new optional parameter to select which implementation is used, and > then you can remove it when you are happy with the new implementation. > > For wfs and wfs-ng applications changed their dependency, the new jar > responded to the same connection parameters as the old one. > -- > Jody Garnett > > > On Fri, 26 Jun 2020 at 09:45, Travis Brundage <travislbrund...@gmail.com> > wrote: > >> Hi all, >> >> Jumping back into this issue, I was hoping to confirm my understanding of >> the suggestion. >> >> Is the idea to create a separate new DataStore for my changes, and then a >> separate new DataStoreFactory which can create the new DataStore using >> params from the old one? Would this require a whole separate module in the >> way gt-wfs-ng was? >> >> I can sort of imagine how those would look, but what's missing for me is >> how to actually use them. Unfortunately, I couldn't find much in the way of >> how to upgrade gt-wfs to gt-wfs-ng. >> >> Essentially, I am not sure what a migration looks like or how a user >> would activate it. Is it something a user does manually, or happens >> automatically in GeoServer somehow? >> >> Cheers, >> Travis >> >> On Fri, May 29, 2020 at 8:56 PM Jody Garnett <jody.garn...@gmail.com> >> wrote: >> >>> I think you can also be a little relaxed as this is a community module; >>> if folks wanted stability they would be helping you. >>> -- >>> Jody Garnett >>> >>> >>> On Fri, 29 May 2020 at 17:14, Travis Brundage <travislbrund...@gmail.com> >>> wrote: >>> >>>> Hey Jody, thanks for the tip! I'll check out that gt-wfsng and gt-wfs >>>> and update my PR with a proper migration strategy with a datastore factory >>>> like you suggest. >>>> >>>> Cheers, >>>> Travis >>>> >>>> On Fri, May 29, 2020 at 4:11 PM Jody Garnett <jody.garn...@gmail.com> >>>> wrote: >>>> >>>>> We have done this before, you can set up an additional datastore >>>>> factory that reads the old parameter values and creates he new datastore >>>>> instance to give folks a chance to migrate smoothly. This is how we made >>>>> the change from things like gt-wfs to gt-wfsng >>>>> -- >>>>> Jody Garnett >>>>> >>>>> >>>>> On Tue, 26 May 2020 at 17:51, Travis Brundage < >>>>> travislbrund...@gmail.com> wrote: >>>>> >>>>>> Greetings all, >>>>>> >>>>>> I've pushed some changes to my local branch which allow this to work >>>>>> with any newly created data stores, but the problem is I've changed the >>>>>> internal DataStore itself, which means old data stores won't function >>>>>> properly. Are there any guidelines for migration strategies when making >>>>>> changes to a DataStore? i.e. How can old versions migrate existing data >>>>>> stores without needing to recreate them? >>>>>> >>>>>> Specifically, I've changed the attribute's date format from a String >>>>>> to a List of valid date formats: >>>>>> https://github.com/travisb-fe/geotools/commit/c1e02e0992413453186ab1a649e99791eb6c27d9#diff-c85157669720c9cf0ac769fd6c8b09a1R56 >>>>>> >>>>>> Cheers, >>>>>> Travis >>>>>> >>>>>> On Wed, May 20, 2020 at 10:09 AM Travis Brundage < >>>>>> travislbrund...@gmail.com> wrote: >>>>>> >>>>>>> Hey Jody, >>>>>>> >>>>>>> Thanks for the suggestion here - I think you're right, and it turns >>>>>>> out the plugin is already using this, but it just isn't splitting on >>>>>>> multiple date formats (it's just ingesting it all as a string). So, I >>>>>>> think >>>>>>> that will work - I will just split the incoming string on the logical >>>>>>> or, >>>>>>> and add valid date formats to this property descriptor's user mapping >>>>>>> (as >>>>>>> it already was doing), but now with multiple valid date formats instead >>>>>>> of >>>>>>> just the one. So, same idea, but using the architecture already >>>>>>> available, >>>>>>> sounds great. :) >>>>>>> >>>>>>> Cheers, >>>>>>> Travis >>>>>>> >>>>>>> On Fri, May 8, 2020 at 5:20 PM Jody Garnett <jody.garn...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Thanks for keeping communication up on this Travis, I do not have >>>>>>>> any reason to use Elasticgeo at present but I recognize the effort you >>>>>>>> are >>>>>>>> putting in and thank you. >>>>>>>> >>>>>>>> A quick question - doe each column have a specific date format in >>>>>>>> mind? You could always use the attribute descriptor user map to store >>>>>>>> the >>>>>>>> date format to use. The design recognizes that the "basic" information >>>>>>>> stored in attribute descriptor and attribute type (name/descritor/java >>>>>>>> binding/etc...) may not be enough to get the job done and provides a >>>>>>>> user >>>>>>>> map for you as the developer to track your own extra information such >>>>>>>> as >>>>>>>> this. >>>>>>>> >>>>>>>> If enough datastore's run into the same need that is when we start >>>>>>>> pulling out additional methods to address a common need. >>>>>>>> >>>>>>>> Reference: >>>>>>>> - >>>>>>>> https://docs.geotools.org/latest/javadocs/org/opengis/feature/type/PropertyDescriptor.html#getUserData-- >>>>>>>> -- >>>>>>>> Jody Garnett >>>>>>>> >>>>>>>> >>>>>>>> On Fri, 8 May 2020 at 17:02, Travis Brundage < >>>>>>>> travislbrund...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> I wanted to discuss here some proposed changes to the elasticgeo >>>>>>>>> plugin related to handling multiple valid date formats, as reported in >>>>>>>>> [GEOT-6577] <https://osgeo-org.atlassian.net/browse/GEOT-6577>. >>>>>>>>> >>>>>>>>> As I've mentioned in the ticket, the core reason this issue is >>>>>>>>> happening is that the DataStore expects there to be just one valid >>>>>>>>> date >>>>>>>>> format, and that is what it will use for the attribute. Elasticsearch >>>>>>>>> is >>>>>>>>> not as strict, and permits mappings of multiple valid date formats >>>>>>>>> for an >>>>>>>>> index, meaning we can get data with different date formats for the >>>>>>>>> same >>>>>>>>> attribute. >>>>>>>>> >>>>>>>>> To allow this functionality, I plan to change the dateFormat to a >>>>>>>>> List of String objects, and rename it to validDateFormats. When >>>>>>>>> reading the >>>>>>>>> feature, just iterate through the List looking for a date format which >>>>>>>>> matches the data value. When the data store is parsing the date >>>>>>>>> format from >>>>>>>>> elastic, the List will be assigned to the format received, split on >>>>>>>>> each ||. >>>>>>>>> >>>>>>>>> I welcome input on the design here, if there's a more reasonable >>>>>>>>> way to accomplish this. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Travis >>>>>>>>> _______________________________________________ >>>>>>>>> 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 > -- Regards, Andrea Aime == 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 di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- *Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.*
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
