proposal to move jdbc-ng to supported

[Justin Deoliveira]

Here it is:

It was actually already started, I just had to tweak it a bit.

http://docs.codehaus.org/display/GEOTOOLS/Next+Generation+JDBC+DataStore

It is more or less ready for voting, which I think at this point is just
a formality.

In terms of things to do:

* Updating user guide

Done, if someone could review that would be great:

http://docs.codehaus.org/display/GEOTDOC/11+JDBC

It is still pretty basic, but a little better than what was there before.

Andrea/Christian: If you could update the respective pages for your
modules adding any information that you think is relevant that would be
helpful.

* Sample code

I have new demo module sitting in my local sandbox waiting to be
comitted. I don't want to do it before the modules are moved since it
would have to depend on unsupported modules.

* Updating Module Matrix

Done for jdbc-core, still need to do so for plugins.

http://docs.codehaus.org/display/GEOTOOLS/JDBC+Module

If we get enough +1 votes before weeks end I can move the modules over
on the weekend to try and avoid disrupting most people.

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Jody Garnett-2]

Hi Justin:

Only small stupid feedback; in your proposal page the final directory  
structure has an unsupported/jdbc directory.
- is this needed anymore? If jdbc-core is being folded into library/
jdbc?
- or is it used to hold onto the jdbc-ng modules that are not ready  
yet? (if so could you list them....)

Thanks for updating the documentation pages; the review.txt link is  
busted at the moment (prior to you merging I guess).

So +1 here.

Jody

On 02/07/2009, at 11:09 PM, Justin Deoliveira wrote:

> Here it is:
>
> It was actually already started, I just had to tweak it a bit.
>
> http://docs.codehaus.org/display/GEOTOOLS/Next+Generation+JDBC+DataStore
>
> It is more or less ready for voting, which I think at this point is  
> just
> a formality.
>
> In terms of things to do:
>
> * Updating user guide
>
> Done, if someone could review that would be great:
>
> http://docs.codehaus.org/display/GEOTDOC/11+JDBC
>
> It is still pretty basic, but a little better than what was there  
> before.
>
> Andrea/Christian: If you could update the respective pages for your
> modules adding any information that you think is relevant that would  
> be
> helpful.
>
> * Sample code
>
> I have new demo module sitting in my local sandbox waiting to be
> comitted. I don't want to do it before the modules are moved since it
> would have to depend on unsupported modules.
>
> * Updating Module Matrix
>
> Done for jdbc-core, still need to do so for plugins.
>
> http://docs.codehaus.org/display/GEOTOOLS/JDBC+Module
>
> If we get enough +1 votes before weeks end I can move the modules over
> on the weekend to try and avoid disrupting most people.
>
> -Justin
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Geotools-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[mbedward]

Thanks Justin.
+1 from me

Michael

------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Ben Caradoc-Davies]

+1 from me. Nice work.

--
Ben Caradoc-Davies <[hidden email]>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Justin Deoliveira]

Justin Deoliveira wrote:

> Here it is:
>
> It was actually already started, I just had to tweak it a bit.
>
> http://docs.codehaus.org/display/GEOTOOLS/Next+Generation+JDBC+DataStore
>
> It is more or less ready for voting, which I think at this point is just
> a formality.
>
> In terms of things to do:
>
> * Updating user guide
>
> Done, if someone could review that would be great:
>
> http://docs.codehaus.org/display/GEOTDOC/11+JDBC
>
> It is still pretty basic, but a little better than what was there before.
>
> Andrea/Christian: If you could update the respective pages for your
> modules adding any information that you think is relevant that would be
> helpful.
>
> * Sample code
>
> I have new demo module sitting in my local sandbox waiting to be
> comitted. I don't want to do it before the modules are moved since it
> would have to depend on unsupported modules.
>
> * Updating Module Matrix
>
> Done for jdbc-core, still need to do so for plugins.

Done for H2, DB2, and PostGIS.

http://docs.codehaus.org/display/GEOTOOLS/JDBC+DB2
http://docs.codehaus.org/display/GEOTOOLS/JDBC+H2
http://docs.codehaus.org/display/GEOTOOLS/JDBC+PostGIS

>
> http://docs.codehaus.org/display/GEOTOOLS/JDBC+Module
>
> If we get enough +1 votes before weeks end I can move the modules over
> on the weekend to try and avoid disrupting most people.
>
> -Justin
>


--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[aaime]

Justin Deoliveira ha scritto:
> Here it is:
>
> It was actually already started, I just had to tweak it a bit.
>
> http://docs.codehaus.org/display/GEOTOOLS/Next+Generation+JDBC+DataStore
>
> It is more or less ready for voting, which I think at this point is just
> a formality.

I'm +1, but there are a few little things that are not fully ok and
that I hope we can sort out quickly:
* dbtype: postgisng and oracleng. What should we do about those?
   The names were set so that we can have old and new postgis in the
   same container without creating a mess. And it is still needed today,
   e.g., if you want to have versioning and postgisng in the same
   classpath, as versioning depends on the old postgis.
   I guess a more future proof dbtype could be postgis2, oracle2
* postgisng still has a functional regression compared to postgis,
   lack of ability to use estimated extents:
   http://jira.codehaus.org/browse/GEOT-2572
   My fault, I need to cook up a patch, will try to do soon (I don't
   consider it a blocker for graduation)
* the proposal does not say what the contents of unsupported/jdbc will
   be (is it a copy of the old library/jdbc, or that is kept there
   and deprecated)

Cheers
Andrea


--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Justin Deoliveira]

Andrea Aime wrote:

> Justin Deoliveira ha scritto:
>> Here it is:
>>
>> It was actually already started, I just had to tweak it a bit.
>>
>> http://docs.codehaus.org/display/GEOTOOLS/Next+Generation+JDBC+DataStore
>>
>> It is more or less ready for voting, which I think at this point is
>> just a formality.
>
> I'm +1, but there are a few little things that are not fully ok and
> that I hope we can sort out quickly:
> * dbtype: postgisng and oracleng. What should we do about those?
>   The names were set so that we can have old and new postgis in the
>   same container without creating a mess. And it is still needed today,
>   e.g., if you want to have versioning and postgisng in the same
>   classpath, as versioning depends on the old postgis.
>   I guess a more future proof dbtype could be postgis2, oracle2

Good point. What do you think about the following:

* We add a dynamic check for the old datastores in the classpath. When
they are present postgis only matches "postgisng" (or "postgis2"), and
same for oracle. When they are not present however, the datastore will
match just "postgis", as well as "postgisng". Then when the old
datastores are truly removed (2.7 i guess) we can remove the classpath
check, and have them match either "postgis", or "postgisng".

Thoughts?

> * postgisng still has a functional regression compared to postgis,
>   lack of ability to use estimated extents:
>   http://jira.codehaus.org/browse/GEOT-2572
>   My fault, I need to cook up a patch, will try to do soon (I don't
>   consider it a blocker for graduation)
Noted. I agree probably not a blocker for graduation but we should try
to address it sooner rather than later.

> * the proposal does not say what the contents of unsupported/jdbc will
>   be (is it a copy of the old library/jdbc, or that is kept there
>   and deprecated)
Oops, I forgot to remove that as per our agreement to merge
jdbc-ng/jdbc-core into the old jdbc module, and keep the old jdbc
classes around, just deprecating them. Docs updated.
>
> Cheers
> Andrea
>
>


--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[aaime]

Justin Deoliveira ha scritto:

>> I'm +1, but there are a few little things that are not fully ok and
>> that I hope we can sort out quickly:
>> * dbtype: postgisng and oracleng. What should we do about those?
>>   The names were set so that we can have old and new postgis in the
>>   same container without creating a mess. And it is still needed today,
>>   e.g., if you want to have versioning and postgisng in the same
>>   classpath, as versioning depends on the old postgis.
>>   I guess a more future proof dbtype could be postgis2, oracle2
>
> Good point. What do you think about the following:
>
> * We add a dynamic check for the old datastores in the classpath. When
> they are present postgis only matches "postgisng" (or "postgis2"), and
> same for oracle. When they are not present however, the datastore will
> match just "postgis", as well as "postgisng". Then when the old
> datastores are truly removed (2.7 i guess) we can remove the classpath
> check, and have them match either "postgis", or "postgisng".
>
> Thoughts?

Sounds like a good plan. It will somehow crack when anybody needs
to use versioning postgis since that will carry along the old
postgis datastore, so the connections using "postgis" will fall back
on using the old datastore.
I will have to find time to port the versioning datastore to the
new architecture... hmmm... may not happen anytime soon :(

http://jira.codehaus.org/browse/GEOT-2598

>> * the proposal does not say what the contents of unsupported/jdbc will
>>   be (is it a copy of the old library/jdbc, or that is kept there
>>   and deprecated)
> Oops, I forgot to remove that as per our agreement to merge
> jdbc-ng/jdbc-core into the old jdbc module, and keep the old jdbc
> classes around, just deprecating them. Docs updated.

Nice, thank you
Cheers
Andrea


--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Jody Garnett-2]

> Good point. What do you think about the following:
>
> * We add a dynamic check for the old datastores in the classpath. When
> they are present postgis only matches "postgisng" (or "postgis2"), and
> same for oracle. When they are not present however, the datastore will
> match just "postgis", as well as "postgisng". Then when the old
> datastores are truly removed (2.7 i guess) we can remove the classpath
> check, and have them match either "postgis", or "postgisng".
>
> Thoughts?

There may be an easier idea ... have the datastore factory respond
support the old dbtype as well -  but place use one of those factory
ordering hints to make it a lower priority. This is easier then
checking the classpath is it not?

Jody

Jody

------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel