You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Playing around with some things today I found out that mopidy-mobile seems to send searches incorrectly. Mopidy-Spotify see it as a search for "f" "o" "o" " " "f" "i" "g" "h" "t" "e" "r" "s" while, Mopidy-Local-Sqlite seems to handle it "correctly". I suspect we want to normalize the query in core so that we at least call the backends in a consistent way.
So input of "query":{"any":"foo fighters"} should log a warning and convert the query to "query":{"any":["foo fighters"]}
Additionally, we should check if there are bugs related to this in mopidy-mobile and/or mopidy-local-sqlite as I think they differ from the intended behavior for the API.
/me looks forward to switching to a new search API sometime in the future.
2015-03-21 23:32:53,642 DEBUG [HttpServer] /home/adamcik/dev/mopidy/mopidy/http/handlers.py:115
mopidy.http.handlers Received WebSocket message from 127.0.0.1: u'{"method":"core.library.search","params":{"query":{"any":"foo fighters"},"uris":null},"jsonrpc":"2.0","id":1}'
2015-03-21 23:32:53,644 DEBUG [LocalBackend-3] /home/adamcik/dev/mopidy-virtualenv/local/lib/python2.7/site-packages/mopidy_local_sqlite/schema.py:224
mopidy_local_sqlite.schema SQLite search query [u'foo fighters']:
SELECT *
FROM tracks
WHERE docid IN (SELECT docid FROM fts WHERE fts MATCH ?)
2015-03-21 23:32:53,747 DEBUG [Core-9] /home/adamcik/dev/mopidy-spotify-2/mopidy_spotify/utils.py:15
mopidy_spotify.utils Playlist fetch took 101ms
2015-03-21 23:32:53,747 DEBUG [SpotifyBackend-5] /home/adamcik/dev/mopidy-spotify-2/mopidy_spotify/library.py:230
mopidy_spotify.library Searching Spotify for: "f" "o" "o" " " "f" "i" "g" "h" "t" "e" "r" "s"
The text was updated successfully, but these errors were encountered:
Question is, whether queries should be normalized (as currently done by Mopidy-Local-SQLite et al.) or if these should fail with a meaningful error message so clients are forced to fix this.
Playing around with some things today I found out that mopidy-mobile seems to send searches incorrectly. Mopidy-Spotify see it as a search for
"f" "o" "o" " " "f" "i" "g" "h" "t" "e" "r" "s"
while, Mopidy-Local-Sqlite seems to handle it "correctly". I suspect we want to normalize the query in core so that we at least call the backends in a consistent way.So input of
"query":{"any":"foo fighters"}
should log a warning and convert the query to"query":{"any":["foo fighters"]}
Additionally, we should check if there are bugs related to this in mopidy-mobile and/or mopidy-local-sqlite as I think they differ from the intended behavior for the API.
/me looks forward to switching to a new search API sometime in the future.
The text was updated successfully, but these errors were encountered: