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

Reply via email to