thelabdude commented on pull request #191: URL: https://github.com/apache/solr/pull/191#issuecomment-870961665
> I think it is possible to use CursorMark in some form for this. > > Given that pagination is semi accurate (and generally not very valuable :)), I think that leaves some attack path opens. > > The CursorMark is really just last values for the sort to be used to indicate the starting offset. > > So you could come up with some caching, loose effort type approaches I think. > > For deep paging, it seems likely worth some effort. I started to look into it, but the actually value and likely practical is so low. > > I'm +1 on starting here. Agreed ... the reason I didn't think caching would work is requests to the `/sql` handler get load balanced across potentially many nodes. Also given the rows / cols nature of SQL result sets, it's hard to pass back the next `cursorMark` to the client to include in the next paging request. So I guess you could cache the next cursorMark with the SQL + params as the key in a global distributed cache (znode) but that feels like a lot of complexity for a questionable SQL use case? It's not lost on me that deep paging is dangerous when exposed to web crawlers but that doesn't seem like it's as much of a risk with SQL. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
