I mean… there’s a lot: PhotoStructure | How to search your PhotoStructure library
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)
2 Likes
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.
1 Like
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…
1 Like
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:2021and have it group bymonth -
camera:nikonand group bylensoraperture
The above examples make use of your pre-existing keywords but would be good to also group by user-defined keywords and hierarchies
1 Like
(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?
(did you see what happens when you click the search button in, say,
tags/Camera/Nikon?)
Not until you mentioned it! I really like it - especially when browsing fs, which can get quite deep.
Interesting! Feel free to create a new feature request for this: I’d vote for it.
Thanks! will do
How would you expect it to handle very large groups, though? Would it automatically switch to “random sample” mode?
I imagined it would always be in random sample mode. I guess it would surprise me if Photostructure deviated from this behaviour. Each group would just contain a random sample of results like everywhere else in ps 
Unless you mean: what if there are so many values to group by? Like what if I want to group by lens, but I own 100 lenses? Good question - I guess I’d expect I’d be able to see 100 groups albeit only popping into existence as I scroll down the page.
Would like to be able to search by video duration. My library has all of these 2-3s videos, I think from my wife’s iphone. It would be nice to be able to screen those out and only see the longer videos. Not sure if this is a possibility or not…
It’s totally possible: the duration column isn’t currently indexed though.
World you expect all images to be excluded if you search with something like duration:>2s?
Yes, I think I would expect it to exclude images if I was searching duration.
I would like to be able to search by filename.
I would also like search results to indicate how many assets are returned.
This would be helpful when there are zero assets (right now if nothing comes up, I’m not sure if it’s because my computer is still processing or if there are actually no results). This would also be helpful when trying out different combinations of search queries, to see if your input is actually impacting the results.
3 Likes
I second this. I don’t have nicely curated tags and content. Nor are my file names or folders descriptive of their content.
This is actually the single feature I want most