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
