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
