Hey Andrea, thanks for the Strategy suggestion - that actually sounds simpler to me so I'll give that a shot. Of course, I still will need sjudeng's approval on the PR.
Cheers, Travis On Sat, Jun 27, 2020 at 1:56 AM Andrea Aime <andrea.a...@geo-solutions.it> wrote: > 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
