[gdal-dev] RE: Optimizing random access in SQL result set of OGR DB drivers

[Even Rouault]

Selon Martin Chapman <chapmanm at pixia.com>:

> Even and Frank,
>
> 1.  I would absolutely not change any existing functionality of how FID is
> handled or you will screw up everyone's code that depends on that and will
> cause a lot of people serious grief.
>
> 2.  I cannot remember exactly but I think SetNextByIndex was intended to
> solve this problem because I originally asked Frank to add it so I would
> look there first as Frank says.  Not sure why I couldn't use it in my case
> but I think there was a reason.
>
> 2.  If SetNextByIndex doesn't work for this case and you want to add ordinal
> row support perhaps adding a new interface (or inherited class) would be the
> answer.  That way you don't screw up existing drivers and changes can be
> implemented gradually driver by driver where it makes sense.  Maybe the new
> interface would be called IRandomAccessCursor or something like that but to
> match the OGR interface naming convention.
>
> How does that sound?

Why would you need a new interface ? Calling SetNextByIndex(nIndex) followed by
GetNextFeature() is exacly what you want, unless I have missed something.
SetNextByIndex() would just need to be implemented on those layers and
GetNextFeature() adapted to take it into account

>
> Martin
>
> -----Original Message-----
> From: Frank Warmerdam [mailto:warmerdam at pobox.com]
> Sent: Wednesday, August 26, 2009 4:02 PM
> To: Even Rouault
> Cc: Martin Chapman; Gdal-Dev
> Subject: Re: Optimizing random access in SQL result set of OGR DB drivers
>
> Even Rouault wrote:
> > Martin,
> >
> > I take the liberty to CC the list, as it is an interesting issue and it's
> better
> > to go public if we want to make progress on that.
> >
> > In a few words, this is about how we could speed up GetFeature() on the
> layers
> > returned when issuing a SQL request on OGR drivers that rely on databases
> : PG
> > driver, MySQL driver, SQLite driver (... ?). For people wanting to take
> part,
> > you might be interested in the below email exchange first.
> >
> > After examining Martin's patches and reading its explanations, I cann see
> 2
> > possibilities if we want to implement such optimization :
>
> Even,
>
> I haven't seen Martin's patches, but the normal way to provide indexed
> access to resultsets is the OGRLayer::SetNextByIndex() method.  You
> pass the index into the current result set and then GetNextFeature()
> should read the indicated feature.
>
> Currently only very few providers implement this in a customized way,
> but it seems it would be better to expand that rather than introduce
> a new mechanism.
>
> Does this make sense?
>
> PS. there are reasonably good reasons why we want the FID to be the
> primary key where practical.  I would hate to break that.
>
> Best regards,
> --
> ---------------------------------------+------------------------------------
> --
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
>