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

Reply via email to