[Fdo_dev] About RDBI's get_gen_id() function

[Mateusz Loskot]

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