WebStorage proxy can't deal with associated data

[luismerino]

REQUIRED INFORMATION

Ext version tested:

• Touch 2.0PR3

Browser versions tested against:

• Chrome 17
• Safari 5.1.2

Description:

• WebStorage proxies don't use their reader/writer instances, therefore associated data is left out when using these types of proxy.

// Product Model
Ext.define('Product', {
    fields: [
        {name: 'pid', type: 'int'},
        {name: 'name', type: 'string'}
    ],
    associations: [{
        type: 'belongsTo',
        model: 'Category'
    }]
});


// Category Model
Ext.define('Category', {
    extend: 'Ext.data.Model',
    fields: [
        {name: 'id', type: 'int'},
        {name: 'name', type: 'string'}
    ],
    proxy: {
        type: 'localstorage',
        id  : 'my-categories'
    },
    hasMany: {
        model: 'Product',
        name : 'products',
        filterProperty: 'pid',
        proxy: {
            type: 'localstorage',
            id  : 'products'
        }
    }
});


// Categories Store
Ext.define('Categories', {
    extend: 'Ext.data.Store',
    model: 'Category',
});

var c = new Categories();
c.loadData([
    {
        id: 1,
        name: 'First Category',
        products: [
            {
                pid: 1,
                name: 'First Product'
            }
        ]
    }
]);


c.sync();

Refresh browser window, then:

var c = new Categories();
c.load({success: function(records){ console.log(records); }});

[mitchellsimoens]

Do you have a test case?

[luismerino]

// Product Model
Ext.define('Product', {
    fields: [
        {name: 'pid', type: 'int'},
        {name: 'name', type: 'string'}
    ],
    associations: [{
        type: 'belongsTo',
        model: 'Category'
    }]
});


// Category Model
Ext.define('Category', {
    extend: 'Ext.data.Model',
    fields: [
        {name: 'id', type: 'int'},
        {name: 'name', type: 'string'}
    ],
    proxy: {
        type: 'localstorage',
        id  : 'my-categories'
    },
    hasMany: {
        model: 'Product',
        name : 'products',
        filterProperty: 'pid',
        proxy: {
            type: 'localstorage',
            id  : 'products'
        }
    }
});


// Categories Store
Ext.define('Categories', {
    extend: 'Ext.data.Store',
    model: 'Category',
});

var c = new Categories();
c.loadData([
    {
        id: 1,
        name: 'First Category',
        products: [
            {
                pid: 1,
                name: 'First Product'
            }
        ]
    }
]);


c.sync();

Refresh browser window, then:

var c = new Categories();
c.load({success: function(records){ console.log(records); }});

[TommyMaintz]

Hi,

Thanks for the great test case. We are still discussing internally what the best way would be to implement associations in combination with LocalStorage. Unfortunately this will probably not make it into the next beta release, but we are still hoping on getting this to work before Touch 2.0 GA.

Just wanted to inform you that we are aware of this issue and to not expect this to work in the next beta release.

[luismerino]

Hi,

Thanks for the great test case. We are still discussing internally what the best way would be to implement associations in combination with LocalStorage. Unfortunately this will probably not make it into the next beta release, but we are still hoping on getting this to work before Touch 2.0 GA.

Just wanted to inform you that we are aware of this issue and to not expect this to work in the next beta release.

Thanks for the info. I look forward to see the chosen solution.

[spoussa]

Hi,

Any update to the potential resolution (associations and local-storage)?

If not available in final release, what is the recommended way of saving associations locally? Note, I'd like to use SQL but the author has not fixed the package for ST2 so can't count on that.

[juhovh]

If there is any good temporary workaround for this I would like to hear about it as well. I'm writing a test application with 2.0 beta 3 that relies quite heavily on localstorage, maybe I'll just serialize the objects as JSON and save it to localstorage as string for now... Makes me feel a bit dirty though.

[TommyMaintz]

This is actually the next thing on my list of things to do. The only problem is that we probably won't get a chance to stabilize this functionality before GA, seeing as we are already at RC, so we might release this as experimental with GA and stabilize it separately.

In the meantime I think workarounds that serialize the objects and save them to localstorage as strings are not as hacky as you might think Thats actually pretty much exactly how we store (flat) records in localstorage right now.

[juhovh]

Releasing it as an experimental on GA and final later sounds good. Serializing as strings and saving them to the store is not so hackish if done well, but I did some ugly patching on top to keep the changes minimal and transition to official implementation smoother.

My case is a bit complicated as well, since I'm downloading data from the server with JSON, then making modifications to it locally and saving it to the localstore. Later I read part of the data from localstore and part of the data from the server and display them on a same list, and all this time I have to track duplicates and remove them accordingly.

So if there's need for testing the experimental WebStorage implementation, I can volunteer.

[TommyMaintz]

To anyone interested in a solution for this:

We realize that this type of functionality is something a lot of you would like to see. However, we have once again discussed this feature internally and have decided not to try and implement this for GA. Trying to do this, even as something labeled experimental, could seriously destabilize the data package which is something we just don't want to risk this close to GA. What we plan on doing is creating an example shortly after GA that shows you how you can work around this temporarily until a more permanent solution will be part of the core code base.

What we plan on doing for 2.x is to take a good look at how we can simplify the internal implementation for associations in a way that makes synchronization of models and all its associations both to local storage and server side databases much easier. We have already discussed several possibilities that would maintain 100% backwards compatibility with the current API, but drastically improve the ease of use and performance when loading and saving of all the data.