Jody Garnett ha scritto:
...
>> This is something i am not sure we have discussed yet, migrating from
>> users using the old data store to the new one. Andrea may be able to
>> answer this. Andrea: what would happen for instance if we took the old
>> oracle driver off the classpath, replaced it
Justin Deoliveira wrote:
>> As such; if the modules are still unsupported; the only person you
>> need to answer to is yourself. Proposal would be over kill.
> Ok... I will happy keep working until we are ready to move to
> supported and will pipe up again when that happens.
Sounds good; note tha
Jody Garnett wrote:
> Justin Deoliveira wrote:
>> Hi Jody,
>>
>> First thing i want to make clear is that this is not the proposal to
>> make these things supported, just to restructure and continue to work
>> on getting them to supported. Having them in a single "h2" module is
>> not scaling an
Andrea wrote:
> >> Since I already have classes in my own code base that account for
> >> SQL dialects I can only say that - as time goes by - I find more
> >> and more differences that must be accounted for. I haven't
> >> encapsulated these vendor-specific helper functions as an
> >> interface, r
Justin Deoliveira wrote:
> Hi Jody,
>
> First thing i want to make clear is that this is not the proposal to
> make these things supported, just to restructure and continue to work
> on getting them to supported. Having them in a single "h2" module is
> not scaling and preventing us from effecti
Justin Deoliveira ha scritto:
> Hi Matthias,
>
> You actually make a really good point. One thing we found when
> implementing the oracle dialect is that we did indeed have to change
> the interface quite a bit. Once this interface is "out in the field"
> this will indeed become problematic and w
Hi Matthias,
You actually make a really good point. One thing we found when
implementing the oracle dialect is that we did indeed have to change the
interface quite a bit. Once this interface is "out in the field" this
will indeed become problematic and we won't have the freedom to change
api
Hi Jody,
First thing i want to make clear is that this is not the proposal to
make these things supported, just to restructure and continue to work on
getting them to supported. Having them in a single "h2" module is not
scaling and preventing us from effectively getting the real world
resting
Justin wrote:
> I have thrown together an official proposal for the new jdbc datastore
> stuff:
>
> http://docs.codehaus.org/display/GEOTOOLS/Next+Generation+JDBC+DataStore
>
> Comments/feedback welcome.
Since I already have classes in my own code base that account for SQL dialects
I can only
The module restructuring is interesting; in general I like the layout of
"plugins" "library" etc... it lets people know what they are getting
into ... however I understand that build structure may be non optimal
product packaging.
Can we retire the existing module after this proposal is accepte
Hi all,
I have thrown together an official proposal for the new jdbc datastore
stuff:
http://docs.codehaus.org/display/GEOTOOLS/Next+Generation+JDBC+DataStore
Comments/feedback welcome.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
11 matches
Mail list logo
