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 <[email protected]>
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 <
> [email protected]> 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 <[email protected]>
>> 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 <[email protected]>
>>> 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 <[email protected]>
>>>> 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 <[email protected]>
>>>>> 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 <[email protected]
>>>>>> > 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 <
>>>>>>> [email protected]> 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
>>>>>>>> [email protected]
>>>>>>>> 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
>>>>>>> [email protected]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> * Tom Kunicki* | Software Engineer
>>>>>> *w:* 608 695 4251 *e:* [email protected]
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> * Tom Kunicki* | Software Engineer
>>>> *w:* 608 695 4251 *e:* [email protected]
>>>>
>>>>
>>>
>>
>
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
