Re: [Tracker] Parser stack overflow
- From: Jürg Billeter <j bitron ch>
- To: debarshi ray gmail com
- Cc: Tracker mailing list <tracker-list gnome org>
- Subject: Re: [Tracker] Parser stack overflow
- Date: Tue, 29 Dec 2009 18:12:13 +0100
On Thu, 2009-12-24 at 22:06 +0200, Debarshi Ray wrote:
Somewhere in my program I have a query like this:
return Glib::ustring::compose(
"SELECT ?camera ?exposure ?fn ?focal ?iso ?metering ?white"
"WHERE {"
" ?photo nie:isStoredAs '%1' ."
" OPTIONAL { ?photo nmm:camera ?camera . }"
" OPTIONAL { ?photo nmm:exposureTime ?exposure . }"
" OPTIONAL { ?photo nmm:fnumber ?fn . }"
" OPTIONAL { ?photo nmm:focalLength ?focal . }"
" OPTIONAL { ?photo nmm:isoSpeed ?iso . }"
" OPTIONAL { ?photo nmm:meteringMode ?metering . }"
" OPTIONAL { ?photo nmm:whiteBalance ?white . }"
"}",
uri_);
This causing "parser stack overflow" to be reported in
~/.local/share/tracker/tracker-store.log:
[...]
t13_g."photo_u" = t14_g."photo_u"))': parser stack overflow
It is the last OPTIONAL clause that is causing the problem.
This is a SQLite limitation, which can be avoided by increasing
YYSTACKDEPTH when compiling SQLite. However, the better solution is to
slightly modify the SPARQL query to reduce the complexity of the
generated SQL query. If you add `?photo a nmm:Photo .` right after
`WHERE {`, you shouldn't have any issues with parser stack overflows
anymore.
JÃrg
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]