Re: [Geotools-devel] SQLEncoder

[Rob A. <ro...@so...>]

Justin Deoliveira wrote:
> Perhaps, but writing new code for all of this is easier said then done,
> especially for jdbc. Those modules in particular are built around
> special cases. In rewriting and fixing a lot of the issues, one has to
> be careful to maintain all of the special cases.
>
> Plus the change effects not only postigs, but all the other jdbc
> modules, so it requires agreement from all the jdbc module maintainers
> as well.
>   
This is perhaps the bit I have a problem understanding. If we have 
deprecated an API, then the other module maintainers are affected 
anyway, and to make progress they need to have jdbc fixed, or to move 
away from common code. Wearing a hat of a module maintainer, dependent 
on jdbc, asking for my agreement is actually a bit disempowering - I 
should either maintain my module or see it put into unsupported land or 
out of the build entirely.

To make a decision, I need an assessment of the effort, and an upgrade 
path, bith of which really only exist once someone has done the updates.

Would it be possible to create a doc outline who's doing what in JDBC 
based datastore land. If  I can see a path to push things along I'll 
dive in - but at the moment my way is obscured, master.

For the record, my motivation (and the testing environment I can bring 
to bear) is to support a near-future complex datastore wrapping Oracle, 
PostGIS, Geometryless data stores.  Gabriel will also test against 
ArcSDE.  What I'd like to do is to get the targte wrapped data stores 
working in 2.4.  For geometryless, I've updated it to use the geoAPI 
interfaces largely, I've yet to understand what impact jdbc using old 
API will have - geometryless passes its tests.

Gabriel - do we need the new APIs supported by these stores - or is it 
all abstracted out at a different level and we dont care?
> That being said I do share your desire to quit bandaging and fix the
> source :).
>
> -Justin
>
> Rob Atkinson wrote:
>   
>> Wouldnt it be a hell of a lot easier to update jdbc and then get modules 
>> to follow suit. They are going to have to anyway sooner or later. 
>> Backporting the fix is only to make cite tests work against a single 
>> datastore I suspect?  At some point we need to stop fixing old code, to 
>> create the drivers to move forward and free up resources to make the 
>> necessary move.
>>
>>
>> Justin Deoliveira wrote:
>>     
>>> Hi all,
>>>
>>> I have spent some time rewriting the sql encoder for postgis to be based
>>> off of the geoapi interface. While it yields a lot cleaner code, I had
>>> some problems actually hooking it up to the datastore.
>>>
>>> Both postgis and jdbc are tightly coupled to it so using the new encoder
>>> requires a lot of the same work required to break away postgis from
>>> jdbc. Not trivial to say the least.
>>>
>>> So... I am stuck hacking at the old encoder :(. I have created a jira
>>> task and attached the patches I would like to apply.
>>>
>>> http://jira.codehaus.org/browse/GEOT-1088
>>>
>>> Review would be much appreciated.
>>>
>>> I will also be posting the implementation based off of the geoapi
>>> FilterVisitor for review soon.
>>>
>>> Thanks,
>>>
>>> -Justin
>>>
>>>   
>>>       
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Geotools-devel mailing list
>> Geo...@li...
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>> !DSPAM:1004,458b737e206162223018498!
>>
>>     
>
>
>