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