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
