Even, I agree with your response. Regardless of specific implementation I think your efforts to provide high speed random access searches by ordinal position for the database drivers will be a fantastic addition to the OGR library. I am really excited to check it out when you get it ready for testing.
Best regards, Martin -----Original Message----- From: Even Rouault [mailto:[email protected]] Sent: Wednesday, August 26, 2009 4:33 PM To: Martin Chapman Cc: 'Frank Warmerdam'; 'Even Rouault'; 'Gdal-Dev' Subject: RE: Optimizing random access in SQL result set of OGR DB drivers Selon Martin Chapman <[email protected]>: > 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:[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
