We still can't find their width/height or thumbnail the, but at least
we don't wedge the UI now.
Fixes camlistore.org/issue/389
Change-Id: I8af6cefa5d84e7f6e26f3920e4dd6e1d5eb8b192
Previous value of 1.6 was too small because iPhone 5's aspect ratio
is 1.78, meaning all landscape iPhone 5 photos were included in
is:pano. Same with Moto-X and probably other newer phones.
I tried 1.8, but it still "felt" too small. I think the correct
value is atleast 2.0, but perhaps larger. I don't have enough test
data in that range right now to get a good feel for it.
Change-Id: I6a3e054290d6f434afac8142a9abc68e53008229
Add disc and mediaref (a hash of the audio portion of the
file).
Also relocate taglib code to
third_party/github.com/hjfreyer/taglib-go.
Change-Id: I58364f525b787484af894663125163095256d7c6
Add the title:foo operator to search, to search permanodes which have a
title containing foo, case insensitively.
http://camlistore.org/issue/329
Change-Id: I661df159a4057a889a7ed110b2e724fc6e43b32b
Provides support for case-insensitive string comparisons.
The implementation needs work (e.g. substring searches do
potentially-large allocations).
Change-Id: I30f068094b4617b81aee2e8981f87f6ec2bc0000
Searching for permanodes with zero values for an attribute
returned no results due to a check that at least one value
matched. Only perform that check when a value constraint was
provided.
Change-Id: Ia25a595e4598fe682f2a85babca0b8438681a210
Work in progress, but works enough to commit now. Determing the time
of things has many TODOs, and there's some performance work to be done
(although it still appears to be instant... it just uses more CPU than
it should)
Change-Id: I4b04b5805353dfbde0b841a3a557fd0b7c297780
Also support Width and Height constraints on raw search (not yet
exposed to the expression syntax, but will be like width:<640 or
height:100-200 probably)
Change-Id: I082e3d27b5ef5c238a8e65a6b836943d9f9ff8a6
Search expressions (e.g. "tag:funny location:Portland") can now be
evaluated server-side (expr.go and expr_test.go, still nascent). Next
step is to remove this parsing and construction from the javascript UI
code.
In addition, the search result now contains a continuation token to
continue interating through the result sets in a subsequent query.
The Javascript UI should use this now instead of parsing out
modification times of things and altering the search. If there's no
continuation token, that either means the end has been reached, or
that search type doesn't [yet] support iteration. Currently only
permanode-based queries are supported at many layers, including
continuation, but will be implemented later.
For now, the web UI should send a search query "expression" value of
non-zero length but just whitespace (like a single space: " ") to get
the home page (recently-modified permanodes") because setting both to
the zero value is an input validation error. We should probably make
an expression operator to be more clear here (like "want:permanode
sort:recent"). But the empty space hack works for now.
Change-Id: I3ea92eb8c776159f53c49db1a7439a91c507940a
And quiet noisy logging on normal write failures.
We can now stress test the thumbnail generation by setting
CAMLI_DISABLE_THUMB_CACHE=1 which will make all the thumbnails in the
browsers be unique, and not write them to cache on the server.
Then, when we're happy with the thumbnails, we just increment the
thumbnailVersion string and that busts all the browser- and
server-side caches.
Change-Id: I3cda8e85ab8b1b0b2c9113f6dff613dfbf736028
benchmark old ns/op new ns/op delta
BenchmarkQueryRecentPermanodes 27987 27512 -1.70%
benchmark old allocs new allocs delta
BenchmarkQueryRecentPermanodes 99 87 -12.12%
benchmark old bytes new bytes delta
BenchmarkQueryRecentPermanodes 6433 6207 -3.51%
But will be better in practice with more blobs.
Change-Id: I4673702231c52864249329818145aad11da2b4fc
The WebSockets live queries exposed a latent locking bug: the search
code was acquiring the Corpus read lock multiple times. If a write
came in during the middle of a search, between two read locks, the
second RLock would hang (since a writer lock was pending) and then the
search and write would deadlock.
Instead, just acquire the read lock once at the beginning of the query and
never re-acquire it. For now: new "Locked" versions of all the Corpus APIs.
In the future: will probably just add the locked-or-not into the context, and make
sure all Corpus methods require a *context.Context.
Also fix two potential data races: one with LogicalCondition (which
might've raced on the scratch ss buffer, depending on the query), and
a test-only race that didn't matter in production, but was annoying in
tsan output regardless, so fixed.
More tests to follow later. Unblocking Aaron for now.
Change-Id: Ie1edcbd061235f1ef04f9b4c68b86814c84361af
Realized there was a way more elegant way to implement infinite
scroll. Now it is general to any kind of query (though not yet
to any kind of sorting, as there isn't support for continuing with
arbitrary sorts server-side).
Change-Id: I98dc627e1292524ddd8af8960c134f49ac41f337
If the JavaScript UI is open and the query you're looking at changes
due to new data arriving, the server should push the update search
results to you live, without needing to poll.
Change-Id: I00faf7737f9a459de39b21fb5226a8000feeee2b
Brad Fitzpatrick