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? Martin -----Original Message----- From: Frank Warmerdam [mailto:[email protected]] 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, [email protected] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
