I will update the ContentDataStore patch; it looks great and we have both had a
kick at it. If I can ask you to review my update and then apply we can get this
show on the road.
> In any case, I was wondering how to handle the upgrade.
> Moving the classes in the same package might help the migration, but at
> the very least I would like to get rid of the "ng" since that's going to
> become
> the default thing (if we do another rewrite, are we going to mark it as
> "aab"? (above and beyond?)).
> Maybe be consistent with jdbc and move it to org.geotools.shapefile
>
>
It would be good to handle this as with the last "index" experiment - allow the
factory to make the decision.
Add it to the existing gt-shape module; use a connection parameter to allow
people to try it out for a while. After it has seen a couple releases cut over
to it as the usual implementation the factory produces; deprecate the
AbstractDataStore implementation(s) etc..
Perhaps the connection parameter can be "sorting=true" with a default value of
false.
> And then what... have the new code pick up the old params in case it's the
> only one in the classpath, otherwise redirect to the old store?
>
> it (test, image mosaic), in GeoServer and uDig. Still quite a bit of work
> ahead.
> We also need to test it out quite a bit in all the GeoTools code that depends
> on
>
>
Agreed.
Cheers,
Jody
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
