Moving this to geotools-devel...
On Tue, Jan 13, 2015 at 11:55 AM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:
> Since this is used by Diff (Which is where it is actually added to the
> data) and DiffFeatureReader, it is not entirely internal to
> AbstractDataStore/ContentDataStore.
> As it stands, Diff writes this object to the feature map when a feature is
> removed. This value is then accessed by the TransactionDiff implementation
> (DiffTransactionState or TransactionStateDiff) and the FeatureSource
> (ContentFeatureSource or AbstractFeatureSource) to test if a feature is
> null.
> Consequently, we will need a single implementation (rather than a seperate
> copy). Since we are deprecating AbstractDataStore,
>
> Since TransactionStateDiff will be deprecated along with
> AbstractDataStore, we can move it to its ContentDataStore equivalent,
> DiffTransactionState. Alternatively, since the Diff class actually writes
> this object to the list of features, we could move it up a level to the
> Diff class.
>
> Torben
>
> On Tue, Jan 13, 2015 at 9:48 AM, Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
>> This constant is only used internally (as a placeholder in the data
>> structure to mark deletions). The ContentDataStore support classes take a
>> copy of this placeholder (so it does not get caught up in the deprecation
>> cycle).
>>
>> --
>> Jody Garnett
>>
>> On 13 January 2015 at 09:38, Torben Barsballe <
>> tbarsba...@boundlessgeo.com> wrote:
>>
>>> Little bit more detail here - TransactionStateDiff.NULL is used by:
>>> - ContentFeatureSource (gt-data)
>>> - DiffTransactionState (gt-data)
>>> - AbstractFeatureSource (gt-main)
>>> - Diff (gt-main)
>>> - DiffFeatureReader (gt-main)
>>> - WFSRemoteTransactionState (gt-wfs-ng)
>>>
>>> On Tue, Jan 13, 2015 at 9:03 AM, Torben Barsballe <
>>> tbarsba...@boundlessgeo.com> wrote:
>>>
>>>> One other thing I am looking at is TransactionStateDiff.NULL, which is
>>>> a static final implementation of SimpleFeature, Used by
>>>> TransactionStateDiff (Used by AbstractDataStore), DiffTransactionState
>>>> (Used by ContentDataStore) and various other transaction related methods.
>>>> As part of deprecating AbstractDataStore, we should also be deprecating
>>>> TransactionStateDiff, so this functionality should be moved.
>>>> SimpleFeature is part of opengis rather that geotools, so we can't move
>>>> it strait up to SimpleFeature. That leaves DiffTransactionState as the next
>>>> best option, unless there is somewhere else that would be better. Do you
>>>> have any thoughts on this Jody?
>>>>
>>>> Torben
>>>>
>>>> On Mon, Jan 12, 2015 at 8:38 PM, Jody Garnett <jody.garn...@gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks for the perspective Tom, USGS has at least a year to migrate
>>>>> with support/maintenance loop. I also don't mind if it takes longer if we
>>>>> can give it a safe gt-legacy home to slowly bit-rot.
>>>>> --
>>>>> Jody
>>>>>
>>>>>
>>>>> --
>>>>> Jody Garnett
>>>>>
>>>>> On 12 January 2015 at 20:30, Tom Kunicki <tom.kuni...@weather.com>
>>>>> wrote:
>>>>>
>>>>>> I only mention this because I left the USGS with a number of custom
>>>>>> DataStores to read some obscure formats that inherit from
>>>>>> AbstractDataStore. They like to stay on top of GeoTools/GeoServer
>>>>>> releases
>>>>>> and having to port those would incur a burden. But maybe that would be
>>>>>> mitigated with Torben's new tutorial.
>>>>>>
>>>>>> I do understand the burden of supporting a large set deprecated
>>>>>> codebase... I just wanted to "gut check" removal.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> On Mon, Jan 12, 2015 at 10:02 PM, Jody Garnett <
>>>>>> jody.garn...@gmail.com> wrote:
>>>>>>
>>>>>>> Fair point Tom, and I think we would like to do what we have done in
>>>>>>> the past to move it to a gt-legacy module.
>>>>>>>
>>>>>>> It is not *just* AbstractDataStore here - but all its support
>>>>>>> classes that are proving a burden to support.
>>>>>>>
>>>>>>> For the next round of GeoTools I would like to re-visit an idea
>>>>>>> brought up on this list last year - making improvements to the Query
>>>>>>> object
>>>>>>> to support Transforms.
>>>>>>>
>>>>>>> Why would I care? The transform process, and not gt-transform module
>>>>>>> is too out of the way for casual discovery. By baking it into DataStore
>>>>>>> it
>>>>>>> will be easy for downstream project to integrate. GeoServer can surface
>>>>>>> the
>>>>>>> idea as a Java view, GeoGig can use it to clean up the process of
>>>>>>> importing
>>>>>>> / exporting data. Why would GeoMesa care? It stands a chance of making
>>>>>>> explicit the Query force CRS and Query retroject CRS parameters
>>>>>>> allowing us
>>>>>>> to advertise what is going on more clearly to GeoMesa.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jody Garnett
>>>>>>>
>>>>>>> On 12 January 2015 at 19:34, Tom Kunicki <tom.kuni...@weather.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Is there a reason to consider simply marking AbstractDataStore as
>>>>>>>> deprecated instead of removing it? Is there a maintenance issue with
>>>>>>>> leaving it in the code base?
>>>>>>>>
>>>>>>>> Tom
>>>>>>>>
>>>>>>>> On Mon, Jan 12, 2015 at 7:54 PM, Jody Garnett <
>>>>>>>> jody.garn...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Thanks Torben. You may have a bit of fun with
>>>>>>>>> AbstractDataStoreFactory.Param - take it out as a distinct class.
>>>>>>>>>
>>>>>>>>> I am moving MemoryDataStore and ArrayDataStore to the gt-data
>>>>>>>>> module and may have it ready in time. Most of the fun is cleaning up
>>>>>>>>> gt-main tests that use MemoryDataStore as a quick way to get a feature
>>>>>>>>> collection.
>>>>>>>>>
>>>>>>>>> Here are the details:
>>>>>>>>> - https://github.com/geotools/geotools/pull/686
>>>>>>>>> - https://jira.codehaus.org/browse/GEOT-4982
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jody
>>>>>>>>>
>>>>>>>>> On Mon, Jan 12, 2015 at 2:25 PM Torben Barsballe <
>>>>>>>>> tbarsba...@boundlessgeo.com> wrote:
>>>>>>>>>
>>>>>>>>>> Now that PropertyDataStore has been migrated to extend
>>>>>>>>>> ContentDataStore, we are one step closer to getting rid of
>>>>>>>>>> AbstractDataStore.
>>>>>>>>>> As part of this goal, I have deprecated AbstractDataStore and any
>>>>>>>>>> related classes (Such as AbstractFeatureStore) or classes that
>>>>>>>>>> extend it
>>>>>>>>>> (Such as ArrayDataStore).
>>>>>>>>>> The Pull request can be found here
>>>>>>>>>> <https://github.com/geotools/geotools/pull/685>.
>>>>>>>>>>
>>>>>>>>>> Ideally, the remaining classes that extend AbstractDataStore will
>>>>>>>>>> eventually be migrated to use ContentDataStore, and
>>>>>>>>>> AbstractDataStore can
>>>>>>>>>> be removed in the future.
>>>>>>>>>>
>>>>>>>>>> Torben
>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>> ------------------
>>>>>>>>>> New Year. New Location. New Benefits. New Data Center in Ashburn,
>>>>>>>>>> VA.
>>>>>>>>>> GigeNET is offering a free month of service with a new server in
>>>>>>>>>> Ashburn.
>>>>>>>>>> Choose from 2 high performing configs, both with 100TB of
>>>>>>>>>> bandwidth.
>>>>>>>>>> Higher redundancy.Lower latency.Increased capacity.Completely
>>>>>>>>>> compliant.
>>>>>>>>>> www.gigenet.com_______________________________________________
>>>>>>>>>> Geoserver-devel mailing list
>>>>>>>>>> geoserver-de...@lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> New Year. New Location. New Benefits. New Data Center in Ashburn,
>>>>>>>>> VA.
>>>>>>>>> GigeNET is offering a free month of service with a new server in
>>>>>>>>> Ashburn.
>>>>>>>>> Choose from 2 high performing configs, both with 100TB of
>>>>>>>>> bandwidth.
>>>>>>>>> Higher redundancy.Lower latency.Increased capacity.Completely
>>>>>>>>> compliant.
>>>>>>>>> http://p.sf.net/sfu/gigenet
>>>>>>>>> _______________________________________________
>>>>>>>>> Geoserver-devel mailing list
>>>>>>>>> geoserver-de...@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> * Tom Kunicki* | Software Engineer
>>>>>>>> *w:* 608 695 4251 *e:* tom.kuni...@weather.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> * Tom Kunicki* | Software Engineer
>>>>>> *w:* 608 695 4251 *e:* tom.kuni...@weather.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
