StateRestore ColumnControl saving by column index not column name

bg7

We're running into an issue with StateRestore. It's been working well up until we added a new column to the table that users are using to save states (the new column was added into the middle of the table in terms of column order). As a result, the saved state data appears to no longer line up with the columns they were saved for. I looked at the StateRestore data and I see this:

"columnControl": {
  "2": {
    "searchList": [],
    "searchInput": {
      "logic": "contains",
      "type": "text",
      "value": ""
    }
  },
  "3": {
    "searchList": [],
    "searchInput": {
      "logic": "contains",
      "type": "text",
      "value": ""
    }
  },
  "4": {
    "searchList": [],
    "searchInput": {
      "logic": "contains",
      "type": "text",
      "value": ""
    }
  },
  "6": {
    "searchInput": {
      "logic": "contains",
      "type": "text",
      "value": ""
    }
  },
  "7": {
    "searchList": [],
    "searchInput": {
      "logic": "contains",
      "type": "text",
      "value": ""
    }
  }
},

If we add a new column it has no way to know how to map the saved data to the correct (updated) columns as it's mapping by column index instead of column name. This ends up breaking all of the existing saved states. Am I missing something or don't have StateRestore/ColumnControl configured properly so that it stores this data by column name instead?

Fwiw we're running DataTables 2.3.8, StateRestore 1.4.3 and ColumnControl 1.2.1.

Thanks.

Ben

allan

Hi Ben,

Many thanks for letting me know about this. I think that is ColumnControl specific - I'll have a look into that, hopefully tomorrow, and post back.

Regards,
Allan

bg7

Allan,

Thanks for looking into this. In the meantime we've had our users manually update and resave the saved states that were using old column configurations.

I've been wondering if it ends up being possible to map by column name instead of index if there might be a way to update existing configurations as they're loaded so they get migrated. Ideally it'd be nice if it were transparent to the user. Just thinking out loud.

Thanks.

Ben

allan

Hi Ben,

What I'm currently thinking is, when creating the state object for each column, check if the column has a name. If it does, use that rather than the column index for the property name in the columnControl object. Then when loading the state it will check for the name, and if not found it can check for the column index.

In terms of forwards compat, it means that the old state will be loaded with the column index, and then when the state is next saved, it will be done with the name.

I'm going to try prototyping that just now...

Allan

allan

I've committed the change for this and added a few tests - it appears to be working well.

I'd welcome some feedback on it, but rekgonise that might be a little tricky in this case as that commit is for ColumnControl 2 which requires DataTables 3 - both of which are in beta at the moment. The kicker is that I haven't yet ported StateRestore to DT3. That is something I plan to do very soon - actually it is going to be a rewrite of StateRestore, but previously saved states will still be compatible, even if the UI changes somewhat.

Allan

bg7

Allan,

What you described about using a name if available before failing over to the index I think makes sense. I was also mulling over if there was a way to automatically migrate existing saved configs but I'm not sure what I want to do with that just yet. That may turn out to be more trouble than it's worth.

We've actually been holding off on DT3 until the extensions are ready to go. This is our current list:

JSZip 3.10.1, DataTables 2.3.8, Editor 2.5.2, AutoFill 2.7.1, Buttons 3.2.6, Column visibility 3.2.6, HTML5 export 3.2.6, Print view 3.2.6, ColumnControl 1.2.1, DateTime 1.6.3, FixedColumns 5.0.5, KeyTable 2.12.2, RowGroup 1.6.0, RowReorder 1.5.1, Scroller 2.4.3, Select 3.1.3, StateRestore 1.4.3

https://datatables.net/download/#dt/jszip-3.10.1/dt-2.3.8/e-2.5.2/af-2.7.1/b-3.2.6/b-colvis-3.2.6/b-html5-3.2.6/b-print-3.2.6/cc-1.2.1/date-1.6.3/fc-5.0.5/kt-2.12.2/rg-1.6.0/rr-1.5.1/sc-2.4.3/sl-3.1.3/sr-1.4.3

Happy to be a guinea pig but I assume we need to be patient until the extensions are ready to go, right?

Thanks.

Ben