Hi Jody, Thanks for the extra explanation and information, that helps a lot. I think that's a good path forward, I'll run with that and update the PR so users can select an implementation.
Cheers, Travis On Fri, Jun 26, 2020 at 11:47 AM 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
