Version 1.0.0 added search!
Possible future improvements:
run the queries before suggesting them, and hide suggestions that are empty
Better On This Day support (expand the query to fetch On This Week, or On This Day for the past several years
type-ahead find?
guided UI for adding search terms, (pulldown of available filters, pulldown of operators, …)?
anything else?
Related:
If PS supports date range queries, that would probably be a query I’d like to see. I think you used after and before for that? Then this would also give you an opportunity to show combinations of search terms.
Search by keywords
Search by person
Search by country/state/city/location
Search by rating
Search by any EXIF tag such as EXIF:MyTag=MyValue
An example would be kw:balloon or keyword:balloon, but I’d need to fetch the top-N keywords from the library to give an example that isn’t empty.
who:michael, but again, I’d need to fetch the top-N Who tags from the library to give an example that isn’t empty.
This won’t be in this iteration: I think we discussed having a custom set of indexed exif tags in a prior topic, right? Is there a feature tracking that idea, specifically?
It’s probably a good idea to have an example for every search type (who, kw, date, etc.). Short of that, the search page should at least list all of the possible search types.
example of multiple clauses: kw:balloon OR kw:birthday, who:Alice AND location:'New York'
Ok, I added a recently-updated item, one with a before and after, a prior search history, and an order-by toggle (that toggles between most-recent photos, least-recent photos, and most-recently-updated)
Maybe having filters like Google Photos do, is a good addition
photos this date past years
I don’t know if you can use wildcards in dates for that
date:*-04-08
In the paragraph “What’s a search term” the quoting is a bit misleading: You included the punctuation inside the quotes. I’d suggest to drop the quotes here as you did in the later paragraphs.
Thanks! I just made that change.
That’s not currently implemented, but it’s certainly doable, and I like that format!
The way I store captured-at would let me easily do that query, as it’s in “local formatted centiseconds”: now is 2021050908321200.
SELECT *
FROM Asset
WHERE Asset.capturedAtLocal/100000000 % 10000 BETWEEN 503 AND 513;
but it’d be an Asset index scan.
I’ll get to this after I get first passes at albums and deletions finished. 
If you’d like to support this, it might make sense to store year, month, day as separate fields (additionally). However, I have no experience how well SQLite supports arbitrary combinations of fields in its queries (bitmap indices maybe)?
Just as fodder for thought, if SQLite performance ever becomes an issue for search performance: In my day job, I’ve had a good experience with using Lucene (or rather Solr, which uses Lucene indices as it’s backend) for arbitrary combinations of search terms on large databases (tens of millions of documents). But that has of course its own challenges…
I’ll keep that in mind if the performance is bad. I haven’t had to denormalize much of anything yet in the schema: SQLite seems to be doing great, as long as there’s a relevant index.
I actually coded next to one of the inventors of Solr as he invented it (15 years ago)!
For Docker users, this wouldn’t be bad: add a couple apk install commands and all’s well. Docker consumers don’t even seem to care about image size (although I do a multi-step build and use Alpine to keep photostructure/server as small as possible!)
PhotoStructure for Desktops is cross-platform, and I’m very hesitant to add larger dependencies there, though. I’d love to use Postgres, for example. SQLite is only 2MB, and Postgres’ installer is ~300MB. The entire PhotoStructure for Desktops installer is currently half that. Lucene/Solr is similar. Great tool, but a huge wad of code that would come with it.
Sometimes, the world is rather small 
Totally understandable. The cost of such an additional dependency and - probably even worse - maintaining an additional index data structure or even replacing the existing database would be quite high.
PhotoStructure could probably get away with using Lucene directly, although this might get complicated if you are using multiple workers writing to the index. Anyway, I didn’t intend to suggest a change here - just wanted to put a little bit of knowledge out there.
You can just have a generated column in SQLite with an index, so you don’t need to worry about inconsistent updates
i dont know how far along keyword search is but i searched dog, kw:dog, kw:party. and these all turned up nothing.
PhotoStructure currently has no ML tagging, so those “dog” or “party” tags would need to be in your file metadata already.
Also related:
Hi! Loving the new search!
Currently a search result is a big collection of everything that matches. Would be good if there was some way of organizing the results.
I’m thinking: would it be possible to add a group by to search results? So, group by whatever keyword you type (or pick from drop down).
For example I could search for:
date:2021 and have it group by month
camera:nikon and group by lens or aperture
The above examples make use of your pre-existing keywords but would be good to also group by user-defined keywords and hierarchies
(did you see what happens when you click the search button in, say, tags/Camera/Nikon?)
Interesting! Feel free to create a new feature request for this: I’d vote for it.
How would you expect it to handle very large groups, though? Would it automatically switch to “random sample” mode?