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
