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

W Khattak Wajid.Khattak at keynetix.com
Tue Feb 17 11:40:41 EST 2009


Hi Jason,

I just wanted to ask that what sort of technique are you using for getting a
subset of features from MG for a particular search? The problem is that the
kind of data I am working with contains huge amounts of features per data
source and I have a search page where the results are shown in a paged Grid
View. Initially I thought about caching the results in SQl Server whereby
when the user performs the search for the very first time , the attributes
of the features are put into a table & then using custom paging, getting
only 10 rows while the user is paging through the results and to re-insert
new rows when the user changes the search criteria. Clearly this doesn't
sound good as there is no way of checking if the cache is invalid or not
unitl and unless you query MG again. I have thought about a few ways but
cann't really think of a good solution for caching MG's results or
alternatively getting only a subset of features from MG.

regards,

W Khattak





Jason Birch wrote:
> 
> 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.
> 
>  
> 
> 
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> 
> 

-- 
View this message in context: http://n2.nabble.com/RFC-26---New-Extended-Select-command-and-Scrollable-Reader---for-review-tp2051824p2341835.html
Sent from the FDO Internals mailing list archive at Nabble.com.



More information about the fdo-internals mailing list