Tune Search Concept

[jwjacobson]

The app will offer two different ways to search: simple and advanced.

Simple search is what exists currently in its most basic form: it searches all rows for the search term. It is useful for basic functionality: see all the tunes by a composer, search by title, search by year, search by song form, etc. This works because there isn't a lot of overlap between field data, e.g.. AABA is only a song form, Powell is only a composer, 1947 is only a year. The overlap and big weakness of simple search is that it is difficult to search by key since the key letters overlap with parts of the titles, composers, song forms (though this is less of an issue for minor keys (C-), sharp keys (C#) and certain flat keys (Gb will never occur in a title but Ab will)). So if you search just "C" you will get all tunes with C in keys or other_keys, but also with C in title, composer, and song form.

Advanced search will address this weakness by allowing the user to search by field using a simple metalanguage in the search bar. This will be less intuitive for most users but should be easy to pick up and will allow for very precise searches. One usage example can be included on the advanced search page with a link to further documentation.

For example, in the current fixture, the search composer:monk key: Ab would return the tune In Walked Bud since it is the only Monk tune in Ab.

Current idea for the metalanguage, it will default to AND connecting the different terms since that is most likely. It should have a contains_key operator that searches both Key and Other Keys fields. An easy syntax is also needed for timeranges. I am also not sure how such a language would be implemented, as doing it all via form validation seem inelegant.

[bbelderbos]

I like where this is going. AND is indeed more common so good default.

For dates we could use human language and use the dateparser package to parse it to a datetime object:
https://pypi.org/project/dateparser/

>>> parse('1 hour ago')
datetime.datetime(2015, 5, 31, 23, 0)

And maybe fall back on the more standard date:YYYY-MM-DD

Something to keep in mind making it more maintainable: ideally the parsing is done separately so that the simple form with meta language + possibly richer form with more fields (not using meta language) can use the same parsing->ORM query logic.