Files.app: Add model classes to manage cache states of new MetadataCache.

Files.app: Add model classes to manage cache states of new MetadataCache.

New MetadataCache enables us to load metadata property one by one.  The CL adds
MetadataCacheItem (for each FileEntry), MetadataCacheItemProperty (for each
property) to manage cache state of each property.

BUG=410766
TEST=FileManagerJsTest.MetadataCacheItemTest

Committed: https://crrev.com/99da03a68f33c2b43b4ea35dfea78a44b491269e
Cr-Commit-Position: refs/heads/master@{#314116}

[hirono, 2015-02-02 05:48:43]

hirono@chromium.org changed reviewers:
+ yawano@chromium.org

[hirono, 2015-02-02 05:48:43]

PTAL? Thanks!

[yawano, 2015-02-02 06:46:30]

https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
File ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item.js
(right):

https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item.js:73:
assert(this.properties_[name].requestId < requestId);
This seems to allow following code to store the data for invalidated requestId.
Is this expected behavior? Is this invalidate call seen as another 'request',
i.e. invalidate does not invalidate requestId but issue a invalidate request
with new requestId?

item.startRequest(1, ['propertyA']);
item.invalidate(1);
item.storeProperties(1, { propertyA: 'value' });

https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item.js:112:
* @public {*}
@public -> @type?

https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
File
ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item_unittest.js
(right):

https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item_unittest.js:5:
var entryA = {
entryA seems not to be used in this test.

[hirono, 2015-02-02 07:24:43]

https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
File ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item.js
(right):

https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item.js:73:
assert(this.properties_[name].requestId < requestId);
On 2015/02/02 06:46:29, yawano wrote:
> This seems to allow following code to store the data for invalidated
requestId.
> Is this expected behavior? Is this invalidate call seen as another 'request',
> i.e. invalidate does not invalidate requestId but issue a invalidate request
> with new requestId?
> 
> item.startRequest(1, ['propertyA']);
> item.invalidate(1);
> item.storeProperties(1, { propertyA: 'value' });

The example case should fail to assert at #73.
Updated the function comment based on the offline discussion.

https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item.js:112:
* @public {*}
On 2015/02/02 06:46:29, yawano wrote:
> @public -> @type?

Closure compiler allows us to use @public {Type} and @private {Type}.
Maybe we should have guideline about this. Let me start the discussion on the
mail thread.

https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
File
ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item_unittest.js
(right):

https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item_unittest.js:5:
var entryA = {
On 2015/02/02 06:46:30, yawano wrote:
> entryA seems not to be used in this test.

Good catch! Thanks!

[yawano, 2015-02-02 07:33:33]

lgtm. Thank you!

https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
File ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item.js
(right):

https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item.js:73:
assert(this.properties_[name].requestId < requestId);
On 2015/02/02 07:24:43, hirono wrote:
> On 2015/02/02 06:46:29, yawano wrote:
> > This seems to allow following code to store the data for invalidated
> requestId.
> > Is this expected behavior? Is this invalidate call seen as another
'request',
> > i.e. invalidate does not invalidate requestId but issue a invalidate request
> > with new requestId?
> > 
> > item.startRequest(1, ['propertyA']);
> > item.invalidate(1);
> > item.storeProperties(1, { propertyA: 'value' });
> 
> The example case should fail to assert at #73.
> Updated the function comment based on the offline discussion.

Acknowledged.

https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item.js:112:
* @public {*}
On 2015/02/02 07:24:43, hirono wrote:
> On 2015/02/02 06:46:29, yawano wrote:
> > @public -> @type?
> 
> Closure compiler allows us to use @public {Type} and @private {Type}.
> Maybe we should have guideline about this. Let me start the discussion on the
> mail thread.

Acknowledged. I didn't know this. Thank you!

[hirono, 2015-02-02 07:33:47]

The CQ bit was checked by hirono@chromium.org

[hirono, 2015-02-02 07:33:57]

On 2015/02/02 07:33:33, yawano wrote:
> lgtm. Thank you!
> 
>
https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
> File
ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item.js
> (right):
> 
>
https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
> ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item.js:73:
> assert(this.properties_[name].requestId < requestId);
> On 2015/02/02 07:24:43, hirono wrote:
> > On 2015/02/02 06:46:29, yawano wrote:
> > > This seems to allow following code to store the data for invalidated
> > requestId.
> > > Is this expected behavior? Is this invalidate call seen as another
> 'request',
> > > i.e. invalidate does not invalidate requestId but issue a invalidate
request
> > > with new requestId?
> > > 
> > > item.startRequest(1, ['propertyA']);
> > > item.invalidate(1);
> > > item.storeProperties(1, { propertyA: 'value' });
> > 
> > The example case should fail to assert at #73.
> > Updated the function comment based on the offline discussion.
> 
> Acknowledged.
> 
>
https://codereview.chromium.org/869923004/diff/40001/ui/file_manager/file_man...
>
ui/file_manager/file_manager/foreground/js/metadata/metadata_cache_item.js:112:
> * @public {*}
> On 2015/02/02 07:24:43, hirono wrote:
> > On 2015/02/02 06:46:29, yawano wrote:
> > > @public -> @type?
> > 
> > Closure compiler allows us to use @public {Type} and @private {Type}.
> > Maybe we should have guideline about this. Let me start the discussion on
the
> > mail thread.
> 
> Acknowledged. I didn't know this. Thank you!

Thanks!

[commit-bot: I haz the power, 2015-02-02 07:34:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/869923004/60001

[commit-bot: I haz the power, 2015-02-02 08:59:51]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-02-02 09:00:55]

Patchset 4 (id:??) landed as
https://crrev.com/99da03a68f33c2b43b4ea35dfea78a44b491269e
Cr-Commit-Position: refs/heads/master@{#314116}