In terms of migration I think it would be ok to drop the data component of
the package... however as you say what happens next time we want to
rewrite... go back to data? What about keeping the same package and just
telling users to try out the new one you can't have the old jar around? Too
harsh?
On Sun, Nov 27, 2011 at 12:34 PM, Jody Garnett <[email protected]>wrote:
> 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
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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
