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).
Ideally, the remaining classes that extend AbstractDataStore will eventually be migrated to use ContentDataStore, and AbstractDataStore can be removed in the future.
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).
Ideally, the remaining classes that extend AbstractDataStore will eventually be migrated to use ContentDataStore, and AbstractDataStore can be removed in the future.
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.
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).
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-devel@anonymised.comsourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
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?
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.
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).
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-devel@anonymised.comsourceforge.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
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.
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.
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?
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.
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).
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-devel@anonymised.comsourceforge.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.
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.
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.
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.
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?
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.
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).
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-devel@anonymised.comsourceforge.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.
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?
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.
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.
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.
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?
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.
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).
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-devel@anonymised.comsourceforge.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.
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).
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)
–
Jody Garnett
On Tue, Jan 13, 2015 at 9:03 AM, Torben Barsballe <tbarsballe@…3839…> 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?
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.
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.
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.
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?
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.
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).
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-devel@anonymised.comsourceforge.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.
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.
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).
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?
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.
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.
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.
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?
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.
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).
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-devel@anonymised.comsourceforge.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.
