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
