Commit graph

168 commits

Author SHA1 Message Date
7c6e607612 basic neopia api integration 2014-01-10 16:25:02 -05:00
b6247fa22f prepare partials for closet_hangers#index, too 2013-12-27 21:48:28 -05:00
f07996d762 cache pet images on items#show, in case that's what's being a super-slow jerkface 2013-12-05 15:22:43 -06:00
8bd7ad5a1e support manually uploaded swf asset images - not the actual uploading, but block them from being reconverted 2013-10-16 15:50:48 -05:00
019303031b choose list when importing from pets 2013-08-17 12:07:04 -04: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
b92131b26c use item proxies in items#index when given item IDs 2013-06-27 00:15:20 -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
a7574f0864 Don't add duplicate hangers now that closet import can specify a list
Bug report that this resolves:

...However, when I was using the "Import from SDB" tool just a few
minutes ago, it ended up adding EVERY neocash item into the "Not
In A List" section, regardless if I already that item imported
into my "Your Items". So, basically.. I had duplicates of
everything and it would not allow me to move them around into
separate catergories or anything. I know that every other time i've
used the import tool, it would only add NEW items that are not
currently already in my lists yet.
2013-06-25 23:40:02 -07:00
3c91f0cde0 import items to a specific list 2013-04-09 15:50:33 -05:00
f547a75c40 ruby 2.0.0 compatibility... hopefully. 2013-02-25 01:14:45 -05:00
e71530a958 only show item zones on outfits#edit occupies filter helper 2013-02-05 11:52:52 -06:00
4efcdaac49 re-enable item translations, now that i made a corresponding server config change 2013-01-28 13:11:28 -06:00
f7ae45e3e7 temporarily disable item translation 2013-01-28 03:30:43 -06:00
206811a2fb oops, deal with missing item fields better 2013-01-28 03:01:25 -06:00
895aef86c2 oops: only infer public locales from language header 2013-01-27 00:35:22 -06:00
8bb553701a remove N+1 queries in contributions#index 2013-01-25 15:23:48 -06:00
dd30fbe0d7 move from with_translations to includes(:translations), since we dont usually care about requiring 2013-01-24 18:26:00 -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
ce4e2fd53c move species to database 2013-01-24 18:25:59 -06:00
965465ca51 move species to database 2013-01-24 18:25:59 -06:00
332a7e67d8 update ItemsController to show new search errors properly 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
c9ae7155b1 locale metadata, including hidden locales for item loading and selection 2013-01-24 18:24:34 -06:00
ef2423e87f globalize3 for items 2013-01-24 18:24:34 -06:00
9c8f7f498f basic translation infrastructure for items - search is still english-only, and probably will have to be replaced with a legit search engine 2013-01-24 18:24:34 -06:00
b22188fa4a locale cookie should be long-term, not a session cookie 2013-01-24 18:24:33 -06:00
0f49d3ed02 simple locale dropdown in layouts#application 2013-01-24 18:24:33 -06:00
d96c54f3cc infer locale from params, then cookies, then Accept-Language header 2013-01-24 18:23:21 -06:00
062f485598 i18n for pets#load flashes 2013-01-24 18:23:21 -06:00
629e5c68a9 i18n for outfits/edit.js userbar message and outfit save errors 2013-01-24 18:23:20 -06:00
029373addd i18n for outfits#destroy flashes 2013-01-24 18:23:20 -06:00
467fb24c42 i18n for closet_hangers#create, closet_hangers#destroy, closet_hangers#update, closet_hangers#update_quantities (flashes, largely intertwined) 2013-01-24 18:23:20 -06:00
e55d407d63 i18n for neopets_pages#create (flashes - holy snap, that was nasty) 2013-01-24 18:23:19 -06:00
0f52ba5b4e i18n for neopets_users#create flashes 2013-01-24 18:23:19 -06:00
7bc255e9c8 i18n for users#index, users#update flashes 2013-01-24 18:23:19 -06:00
3c9e37f614 i18n for broken_image_reports#create flashes 2013-01-24 18:23:19 -06:00
ac0490dc1d i18n for items#show (including javascripts/items/show.js) 2013-01-24 18:23:19 -06:00
5e89e2b947 i18n for items#index (and layouts#items) 2013-01-24 18:23:18 -06:00
132a49d30b i18n for outfits#new (and layouts#application), including caching 2013-01-24 18:23:18 -06:00
bfd825d98e attempt to fix new species_support_ids format. sigh. 2013-01-23 00:25:09 -06:00
9701221035 wardrobe now considers item.species_support_ids when deciding compatibility
For example, the Meerca Maid Tray is a foreground item, so the SWF is marked
as compatible with all body types, but the item itself is clearly marked as
Meercas-only. items#show reflected this properly, but the swf_assets#index
call that the wardrobe uses ignored item.species_support_ids.

So, /bodies/:body_id/swf_assets.json?item_ids[]=... was deprecated in favor
of /pet_types/:pet_type_id/items/swf_assets.json?item_ids=[]..., which is
much like the former route but, before loading assets, also loads the pet
type and items, then filters the items by compatibility, then only loads
assets for the compatible items.
2013-01-02 23:15:32 -05:00
f56b544963 brought-to-you-by on items#show lists contributors 2012-10-24 22:09:05 -05:00
99669b8e4e cache homepage latest contribution 2012-08-09 22:59:35 -04:00
f6d34841ec cache newest items on homepage and items#index 2012-08-09 22:35:30 -04:00
4a69772cd2 remove N+1 queries on current user outfits page 2012-08-09 18:32:33 -04:00
72237f225c modeling hub 2012-08-06 21:15:31 -04:00