[fdo-internals] RFC 26 - New Extended Select commandandScrollable Reader - for review

[Jason Birch]

I was thinking something that limited the total records that were
returned; everything outside of the limit window (start record, num
rows) would not be accessible via the api at all.  Additional results
would require a second select.  This might be a better fit for the
standard select than the scrollable reader?

 

To clarify, in SQL I would do something like this for the first page of
results:

 

SELECT id, name

FROM tablename

LIMIT 0,20

 

And this for the second page:

 

SELECT id, name

FROM tablename

LIMIT 20,20

 

Etc, etc,

 

Because HTTP is stateless, there is no reason to make rows outside of
the selected set available, unless there is some kind of feature cache
at the FDO level that would make subsequent selects more efficient.

 

Jason

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest
Halustchak
Sent: Monday, October 20, 2008 12:49
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 26 - New Extended Select
commandandScrollable Reader - for review

 

Hi Jason,

 

So, this limit would be something that would return an end of fetch
after reading 'limit' number of records? But, then you can reset it I
guess when you want to get the next page (maybe just by calling
ReadAtIndex() again). An issue with the scrollable reader is that you
can read forwards or backwards, and jump to a new record index at any
time. So, I think adding a limit would complicate this mechanism -
knowing when to reset it or what it means after jumping to a new record.

 

Thanks,

Orest.

 

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Monday, October 20, 2008 3:03 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 26 - New Extended Select command
andScrollable Reader - for review

 

I don't have any direct experience with this because MapGuide doesn't
currently doesn't allow access to these commands.  I certainly see value
in making these part of the common feature set though.  Maybe I'll
eventually be able to do sorting on SDF results via MapGuide J

 

One thing that occurred to me when reading this RFC was that I'd like to
see a mechanism to "page" through results; similar to the LIMIT clause
in MySQL.  When displaying result sets in a web environment, you often
want to give the user a small set of the data, and then page through the
results N records at a time.  I can currently brute-force this, but it
would be more efficient to handle this on the FDO side, especially for
providers where the underlying storage format has optimized methods of
dealing with it.  The current enhancements would make this more
efficient to brute-force, but I wonder if adding parameters to the
initial selection (start record, number of results) would make this even
more efficient.

 

Jason

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest
Halustchak
Sent: Monday, October 20, 2008 11:24
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 26 - New Extended Select command
andScrollable Reader - for review

 

Hi,

 

I wonder if anyone has any comments on this. If nobody has any
objections to it, I'd like to bring it to a vote soon.

 

Thanks,

Orest.

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest
Halustchak
Sent: Friday, October 17, 2008 12:37 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RFC 26 - New Extended Select command and
Scrollable Reader - for review

 

Hi,

 

I'd like to bring your attention to RFC 26 (
http://trac.osgeo.org/fdo/wiki/FDORfc26 ) which proposes to add a new
Extended Select command with uses a Scrollable feature reader.
Basically, this takes what currently are custom commands in the SDF,
SHP, and recently SQLite providers and makes them generic FDO commands.
This will remove special case handling for applications that currently
use these and open the door for generic use by any application.

 

Please review and provide your feedback.

 

Thanks,

Orest.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20081020/d5300f76/attachment-0001.html