Advanced Query Syntax

Feature Requests
1

For the well-organized libraries with lots of metadata set, it would be extremely helpful to have queries like

photo.people.contains('John Doe') && photo.people.contains('Alice Doe') && (!photo.people.contains('Bob') || photo.country != 'USA')

I think it will be a killer feature on the market as I don’t think I know any of DAM software that can do that

2

I mentioned something similar in the Asset Search Capability feature request. I absolutely agree that this would be huge.

1 Like
3

Neat idea! As an engineer, I think writing the parser for your query would be great, but I think it’s a lot to ask Grandma or Grandpa to type.

I think we’d be able to get the same functionality with a much simpler query grammar. People are used to Google-style searches, so I expect that would be most intuitive: for every word, try to add it as an “and” term, and if it starts with a minus sign, add it with “and not.”

I think union queries could be handled with parenthesis and using the word “or”.

For each term, if it’s prefixed with a type (like who:alice) that wouldn’t match hits on other indexes, like pathnames, titles, descriptions, or other metadata. No prefix means look everywhere for that term.

Does that sound workable?

(I actually designed the grammar and parser for one of the first “faceted search” engines on the internet: it’s so nice to have SQLite’s FTS index built in already!)

1 Like
4

For Grandmas you can build a simple UI query builder. Something like Query Builder (With User Flow) by Andrew Lucas on Dribbble

I like the prefix idea but I you need to think how to handle terms with spaces and terms that already have colons to avoid ambiguity.

I also suggest to have explicit optional prefix all: as the way to prevent ambiguity.

Regarding FTS index, I suggest to include there as much data as possible, including filename, path, capture dates, date of adding to the library etc.

Also, I don’t know if you do that already, but in case if you have a workflow where originals are copied into your own folder, to keep track of its original name and path. This might be eventually handy for filtering purposes

1 Like
5

Yup, those paths are stored in the AssetFile table.

(If you haven’t taken a peek, try installing https://sqlitebrowser.org/ and point it at your library’s database living at $library/.photostructure/models/db.sqlite3)

1 Like
6

It turns out the query grammar I’ll be shipping in the next beta build will actually let me close this along with the asset search feature :tada: #woot.

Know that there are tons of other things we can add to search, like typeahead-find, better suggested searches, and any other features y’all dream up.

1 Like