GNOME Bugzilla – Bug 774251
BIND after OPTIONAL generates bad SQL
Last modified: 2016-11-20 14:58:15 UTC
The following query: SELECT ?album WHERE { ?album a nmm:MusicAlbum OPTIONAL { ?album nmm:albumArtist ?album_artist } BIND(?album_artist AS ?artist_lower) } results in: Could not run query, near ".": syntax error The associated SQL has some obvious errors, although my SQL knowledge is too non-existent to know how it should be formed: SELECT (SELECT Uri FROM Resource WHERE ID = "1_u") FROM (SELECT * FROM (SELECT t1_g."1_u", t2_g."2_u" FROM (SELECT "nmm:MusicAlbum1"."ID" AS "1_u" FROM "nmm:MusicAlbum" AS "nmm:MusicAlbum1") AS t1_g LEFT JOIN (SELECT "nmm:MusicAlbum_nmm:albumArtist2"."ID" AS "1_u", "nmm:MusicAlbum_nmm:albumArtist2"."nmm:albumArtist" AS "2_u" FROM "nmm:MusicAlbum_nmm:albumArtist" AS "nmm:MusicAlbum_nmm:albumArtist2") AS t2_g ON t1_g."1_u" = t2_g."1_u")"nmm:MusicAlbum_nmm:albumArtist2"."nmm:albumArtist" AS "3_u", ) The bind is the AS statement, which is out of scope and has a trailing comma for a start.
Created attachment 339754 [details] [review] libtracker-data: Handle BIND while in group graph pattern Currently SQL construction fails while using the BIND form inside a group graph pattern, eg. after OPTIONALs. When in that stage, the OPTIONALs will be already resolved to SQL in the "FROM ..." clause as nested SELECTs. As such the generated SQL is wrong, make it handle this case by wrapping the nested SELECTs under "SELECT $bind_value, * FROM (...)" so the value is made available to the wrapping SELECT. The older code still applies when building simple "{ ... . BIND (...) }" clauses.
Pushed the patch to master. Attachment 339754 [details] pushed as 086ac5d - libtracker-data: Handle BIND while in group graph pattern