Extensions Docs Server: Fix samples page and ExampleZipper

Extensions Docs Server: Fix samples page and ExampleZipper

The path for the default images in the samples page was wrong because of recent
branch/channel switches, and ExampleZipper was getting cached unicode data
instead of binary data.

BUG=144672
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=153604

[not at google - send to devlin, 2012-08-27 04:31:47]

Could you add a regression test to samples_data_source_test?

https://chromiumcodereview.appspot.com/10878056/diff/1001/chrome/common/exten...
File chrome/common/extensions/docs/server2/memcache_file_system.py (right):

https://chromiumcodereview.appspot.com/10878056/diff/1001/chrome/common/exten...
chrome/common/extensions/docs/server2/memcache_file_system.py:78: namespace =
'%s.binary' % namespace
is this actually a problem? do we ever read the same path sometimes in binary
and sometimes not? That seems very strange.

https://chromiumcodereview.appspot.com/10878056/diff/1001/chrome/common/exten...
chrome/common/extensions/docs/server2/memcache_file_system.py:95:
self._object_store.Delete(path, namespace)
Is it necessary to delete this? It will be overridden later anyway, and it seems
safer to just leave the old data in there until it gets overridden.

Also it's much fewer operations; we SetMulti in the future, but we're deleting
individually here.

[cduvall, 2012-08-27 18:04:34]

http://codereview.chromium.org/10878056/diff/1001/chrome/common/extensions/do...
File chrome/common/extensions/docs/server2/memcache_file_system.py (right):

http://codereview.chromium.org/10878056/diff/1001/chrome/common/extensions/do...
chrome/common/extensions/docs/server2/memcache_file_system.py:78: namespace =
'%s.binary' % namespace
On 2012/08/27 04:31:48, kalman wrote:
> is this actually a problem? do we ever read the same path sometimes in binary
> and sometimes not? That seems very strange.

Yeah we do, this is why I was getting an error when I tried to download some of
the samples zips. The JSON files for the samples are cached as unicode (because
they are read with binary=False in samples_data_source), and then they are read
with binary=True for the example_zipper. The example_zipper was giving unicode
errors because of this.

http://codereview.chromium.org/10878056/diff/1001/chrome/common/extensions/do...
chrome/common/extensions/docs/server2/memcache_file_system.py:95:
self._object_store.Delete(path, namespace)
On 2012/08/27 04:31:48, kalman wrote:
> Is it necessary to delete this? It will be overridden later anyway, and it
seems
> safer to just leave the old data in there until it gets overridden.
> 
> Also it's much fewer operations; we SetMulti in the future, but we're deleting
> individually here.

Done.

[cduvall, 2012-08-27 23:54:55]

I added the test to example_zipper_test.py btw.

[not at google - send to devlin, 2012-08-28 01:39:09]

lgtm

http://codereview.chromium.org/10878056/diff/1001/chrome/common/extensions/do...
File chrome/common/extensions/docs/server2/memcache_file_system.py (right):

http://codereview.chromium.org/10878056/diff/1001/chrome/common/extensions/do...
chrome/common/extensions/docs/server2/memcache_file_system.py:78: namespace =
'%s.binary' % namespace
On 2012/08/27 18:04:34, cduvall wrote:
> On 2012/08/27 04:31:48, kalman wrote:
> > is this actually a problem? do we ever read the same path sometimes in
binary
> > and sometimes not? That seems very strange.
> 
> Yeah we do, this is why I was getting an error when I tried to download some
of
> the samples zips. The JSON files for the samples are cached as unicode
(because
> they are read with binary=False in samples_data_source), and then they are
read
> with binary=True for the example_zipper. The example_zipper was giving unicode
> errors because of this.

Ok. I would prefer to see a solution which just cached things in binary then
converted to non-binary as needed, but it's a yak that isn't worth shaving yet.