1
0
Fork 0
forked from OpenNeo/impress
Commit graph

26 commits

Author SHA1 Message Date
f4c435c3cd handle user filters 2014-04-02 10:32:13 -05:00
1d11cf6edc better handling of i18n and labels and resource filters and junk 2014-04-02 10:32:13 -05:00
170b7fa6f5 can search items with a form-based query instead of text-based 2014-04-02 10:32:13 -05:00
b6247fa22f prepare partials for closet_hangers#index, too 2013-12-27 21:48:28 -05:00
1ce32e5867 Use item proxies better for items#index?format=html :D
We used get_multi when preparing the proxies to decide which to
load from the database, but then sent multiple get requests to
Memcache to re-fetch the same data from that get_multi. Silly!
Use the data that's already stored on the proxy anyway.
2013-12-27 21:11:03 -05:00
cdffcfbcfd TIL item proxies can read from the cache in bulk 2013-12-09 01:15:57 -06:00
728ff60c5f move item cache sweeping and flex syncing to background tasks 2013-12-09 00:12:05 -06:00
72c59f0b68 if there's only one item search result, redirect to it 2013-07-09 19:54:22 -07:00
4c208c9ac3 instead of returning an empty item list on contradiction, return an empty proxy collection 2013-07-03 18:17:16 -07:00
5e60795f31 Oops, delegate Item::Proxy#to_param to the item, or we get bad links. 2013-06-27 10:47:02 -07:00
5b9394ce82 oops - don't cache as_json's owned/wanted, but instead have the proxy override 2013-06-27 00:10:55 -07:00
9e3cac82ec use proxies for item html, too
Some lame benchmarking on my box, dev, cache classes, many items:

No proxies:
    Fresh JSON:  175,  90,  90,  93,  82, 88, 158, 150, 85, 167 = 117.8
    Cached JSON: (none)
    Fresh HTML:  371, 327, 355, 328, 322, 346 = 341.5
    Cached HTML: 173, 123, 175, 187, 171, 179 = 168

Proxies:
    Fresh JSON:  175, 183, 269, 219, 195, 178 = 203.17
    Cached JSON:  88,  70,  89, 162,  80,  77 = 94.3
    Fresh HTML:  494, 381, 350, 334, 451, 372 = 397
    Cached HTML: 176, 170, 104, 101, 111, 116 = 129.7

So, overhead is significant, but the gains when cached (and that should be
all the time, since we currently have 0 evictions) are definitely worth
it. Worth pushing, and probably putting some future effort into reducing
overhead.

On production (again, lame), items#index was consistently averaging
73-74ms when super healthy, and 82ms when pets#index was being louder
than usual. For reference is all. This will probably perform
significantly worse at first (in JSON, anyway, since HTML is already
mostly cached), so it might be worth briefly warming the cache after
pushing.
2013-06-26 23:50:19 -07:00
e42de795dd Use item proxies for JSON caching
That is, once we get our list of IDs from the search engine, only
fetch records whose JSON we don't already have cached.

It's simpler here to use as_json, but it'd probably be even faster
if I figure out how to serve a plain JSON string from a Rails
controller. In the meantime, requests of entirely cached items
are coming in at about 85ms on average on my box (dev, cache
classes, many items), about 10ms better than the last
iteration.
2013-06-26 23:01:12 -07:00
9d3acf660c in item queries, ignore name filters that are too small or too large 2013-03-29 17:05:14 -05:00
9c6797699e enable hangers in development, disable in production 2013-01-29 23:06:37 -06:00
934923b0f6 sigh. disable user filters again :( 2013-01-28 18:30:04 -06:00
2486e46a25 re-enable user filters, woo 2013-01-28 16:25:00 -06:00
8d72bf6353 temporarily disable user-filters in item search 2013-01-27 01:45:18 -06:00
e86bcfaf54 improve globalized search queries: normalize input, fallbacks, etc 2013-01-26 09:52:58 -06:00
4e0ce6c20b bugfix: zone-not-found raises error again 2013-01-25 11:15:54 -06:00
7f18fe12c1 user:owns, user:wants queries 2013-01-25 10:35:35 -06:00
b2822d901b fix n+1 query for translations on items#index 2013-01-24 18:26:00 -06:00
26ac3782ec move zones to database 2013-01-24 18:26:00 -06:00
cded361f73 update item search to original name-matching behavior
We originally had a regression on name-matching, where, among
other issues, `straw hat` returned items containing both "straw"
and "hat", which isn't really helpful behavior since we're sorting
alphabetically. Now, `straw hat` behaves as expected.

Additionally, "phrases like these" behave as expected, too.
2013-01-24 18:24:35 -06:00
66e0ba28d7 species/zone conditions now render properly, instead of raising parse error from elastic 2013-01-24 18:24:35 -06:00
6e09b8bc10 globalized search first draft
Confirmed features:
    * Output (retrieval, sorting, etc.)
    * Name (positive and negative, but new behavior)
    * Flags (positive and negative)

Planned features:
    * users:owns, user:wants

Known issues:
    * Sets are broken
        * Don't render properly
        * Shouldn't actually be done as joined sets, anyway, since
          we actually want (set1_zone1 OR set1_zone2) AND
          (set2_zone1 OR set2_zone2), which will require breaking
          it into multiple terms queries.
    * Name has regressed: ignores phrases, doesn't require *all*
      words. While we're breaking sets into multiple queries,
      maybe we'll do something similar for name. In fact, we
      really kinda have to if we're gonna keep sorting by name,
      since "straw hat" returns all hats. Eww.
2013-01-24 18:24:35 -06:00