[Fdo_dev] About RDBI's get_gen_id() function

[Badreddine Karoui]

To develop on the generic RDBMS layer or not?
Well, to start I should mention this disclaimer: I'm the wrong person to
argue against using the generic RDBMS layer; that means I'm biased.

It's always easier to go it alone with no API or schedule constrains
and, even better, to have working providers and to cherry pick what you
need from their code and/or their design. In the long run, that may not
be the best solution when you factor in all the cost associated to
adding new features, fixing bugs and other software maintenance cost.
For the second RDBMS provider that we had to develop, it was the
question whether to refactor the first one or build from scratch. In
practical terms, the second option sounds more like clone the first one.
So the answer was obvious.
However, I do understand the difficulties of a new comer that had to
learn how to get around all of that code. As for the refactoring, I wish
we did a better job at accommodating the new PostGIS provider. I think
we still can do that and the question is when. May be this separate
branch for the PostGIS provider is not helping in that regard. IMO the
postGIS provider should be in there with the rest of them and fight for
its right to the generic RDBMS libraries. 

Badreddine

-----Original Message-----
From: fdo_dev-bounces at lists.osgeo.org
[mailto:fdo_dev-bounces at lists.osgeo.org] On Behalf Of Mateusz Loskot
Sent: Thursday, January 11, 2007 12:06 PM
To: fdo_dev
Subject: Re: [Fdo_dev] About RDBI's get_gen_id() function

Badreddine Karoui wrote:
> We've been committing code for over a week into the 3.2.x branch. As
> far as I know everything is ok.

Great.

> How often you need to change code that is not specific to PostGIS 
> provider?

Generally, I try to not to change anything besides PostGIS.
However, I applied some small refactoring to like make ~200 char
lines long :-) shorter to have it easier to analyze the code.
Or replaced some C casts to C++.
But nothing serious.

> This particular change seems to be a no-op as far as the other 
> providers and I'm wondering if this is an isolated an rare event, it 
> should probably be merged sooner than later into the main branches.

This kind of change is the only I made for non-PostGIS code.
However, I've not yet finished, there are still some commands and
capabilities I've not tested.
I'm going to finish testing in 100% till the end of next week.

> We don't want to end up at one point in the future not being able to 
> integrate the PostGIS provider because we would not be allowed to
> make such a change to other providers.

At the beginning of my work I asked if I should follow the Generic RDBMS
style of provider, and I got confirmation that I should.
So, the PostGIS provider is customized to fit Generic RDBMS + GDBI +
RDBI layers, not the other way - all those layers stay untouched.



--- A side note ---

BTW, shortly before holidays I checked the fdooracle sources and I'm
surprised. This provider does not follow Generic RDBMS API and GDBI/RDBI
stuff and I'd say it's much clearer for someone who needs to dig into
the ocean of the FDO provider development without any previous
experience in this matter.
Would you agree that this way of development is recommended and easier?

Honestly, I see a few/some limitations coming from the GDBI layer.
For example, I'd wish to not to use f_spatialcontext* tables at all, but
provide FDO with ready to use SpatialContext* objects,
according to FDO contracts on higher levels.

Unfortunately, I'm not able get rid of those tables, becasue they are
read on level of the Generic RDBMS API.

After some analysis, I see that if I'd go similar way as fdooracle (King
Oracle, as I understand), then the implementation of spatial context in
my provider much more native for PostGIS than it is now.

Could you share your opinion?

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
Fdo_dev mailing list
Fdo_dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo_dev