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