I am trying to create a table having multiple columns and allow user to choose columns to views. For e.g there could be 10 dimensions added in a table but user wants to see only 5 of them , then they should be able to choose 5 out of 10. At the same time we want that to be persisted. So if the same user logs in again he should only see those 5 column he selected earlier similarly every users can have their own selection persisted.
Either you have an external store that you store this into, i.e not Qlik related so pick whatever you are comfortable with.
Or you could store it as a full dynamic property on the object, this however is not something I would recommend as the users would have to have full edit rights on the objects so you will have to edit quite a lot of the default security rules to allow users to persist changes to a published object.
To avoid merge/save conflicts you would have to create 1 variable per user which is pretty horrible as variables will be available in the UI in 2.1
You should never use GenericBookmark for anything besides bookmarks and snapshots as it would blow up your app down the line.
Instead add a normal GenericObject with your own custom type and manage settings in there. Preferably 1 per user to avoid conflicts during app sync between nodes. Adding properties as children or on the object itself creates an area for conflicts if two users are editing during the same saveappobjects cycle.
Now all of this is very overkill just to manage user preferences, I would probably just opt for the browsers local storage if you don't need it to persist between devices.
I understand that the bookmark is not the best aproach. But was is the real problem behind, if a users saves the own properties there. Yes for each save the bookmark is updated and the current selections are saved, but this is just overwriten. And for each user there is only 1 bookmark.
Well you are free to whatever you want to do I'm just very very strongly discouraging anyone thinking about doing something like that as it can have severe performance implications on your app and on your system.
A bookmark will save every distinct field value and it's selections, so if you have a few selections in a few different fields then add 500 users to that and you quite possibly just grew your application size by 500mb.
As opposed to just using normal GenericObjects which would clock in somewhere around 500kb.
There are ways of saving data, it's called GenericObjects. You are free to create your own if you wish.
We are actively trying to avoid hitting the QRS which for a single screen/entity system like Navision or R3 make sense. But for a high performance and click intensive system like Qlik you do not want to query disk/perform IO if you can avoid it. You have a in-memory storage option available, why not use it?