All sorts of new crap and musing on it
Ok, just had weekly meeting. I mentioned the autosave problem. It turns out that Steve has been promising something along those lines. Anyway, we talked about it and the concensus was to repeatedly store the state in the SQL Database. I am a little leery of this for a couple reasons. One is performance. Consistently hitting the database isn't too bad with every page load, but if you do it on every AJAX interaction it may get taxing. The other problem is that this requires me to delve into the backend. I will need to muck with the database which is what I wanted to avoid at this stage.
So I am getting rid of my Session state entirely. There will now be no reason to keep it around since it will be loaded into and taken from SQL every time . However now I will need to define the session information in the database. Since this has to be backwards compatible it has to fit in the definition inside one of 20+ databases. I can abstract this into a datalayer, but it will still get annoying. Also I must make be careful to make big transactions since they are more efficient. Luckily .Net supplies DataTable objects for this very reason.
Another problem is how to index 'state'. There are two basic ways that I see currently. One is to index via user. This would be great but a user can have multiple sessions. So you could index by session id, but if your session id disappears you need a way to get the data.
And how many autosaves do you allow? Do you allow one per session? Do you need to differentiate them? Luckily and unluckily I think I get to determine this.
Ok, it must index by session id. So in your SQL data you will have a user and a session id. So if you lose your session id how do you get the data back? Well, by user of course. But if a user had multiple sessions ('unfinished' sessions) how do you get the right one? One option is to mess up anyone who has multiple sessions open. Another is to make some arbitrary choice. Another is to offer the user multiple autosaves. If you start collecting multiple autosaves you will need a way to manage them (i.e. erase, name).
So we will be getting rid of the SaveTOC page because it will become redundant. Each proto book can be identified with a 'draft TOC ISBN'. On the client side you can catch a session timeout and then report the ID and then redirect to the history page. You will need to be able to discard and rename.
Ok. It will be an Data Control object. This may end up being a DataSet. Changes to SessionOrder will instead change this. This will be heavily dependant on the database scheme which varies on a site to site basis. Oh well.... This is probably a better way to do it to keep with a persistent state vision.
So I am getting rid of my Session state entirely. There will now be no reason to keep it around since it will be loaded into and taken from SQL every time . However now I will need to define the session information in the database. Since this has to be backwards compatible it has to fit in the definition inside one of 20+ databases. I can abstract this into a datalayer, but it will still get annoying. Also I must make be careful to make big transactions since they are more efficient. Luckily .Net supplies DataTable objects for this very reason.
Another problem is how to index 'state'. There are two basic ways that I see currently. One is to index via user. This would be great but a user can have multiple sessions. So you could index by session id, but if your session id disappears you need a way to get the data.
And how many autosaves do you allow? Do you allow one per session? Do you need to differentiate them? Luckily and unluckily I think I get to determine this.
Ok, it must index by session id. So in your SQL data you will have a user and a session id. So if you lose your session id how do you get the data back? Well, by user of course. But if a user had multiple sessions ('unfinished' sessions) how do you get the right one? One option is to mess up anyone who has multiple sessions open. Another is to make some arbitrary choice. Another is to offer the user multiple autosaves. If you start collecting multiple autosaves you will need a way to manage them (i.e. erase, name).
So we will be getting rid of the SaveTOC page because it will become redundant. Each proto book can be identified with a 'draft TOC ISBN'. On the client side you can catch a session timeout and then report the ID and then redirect to the history page. You will need to be able to discard and rename.
Ok. It will be an Data Control object. This may end up being a DataSet. Changes to SessionOrder will instead change this. This will be heavily dependant on the database scheme which varies on a site to site basis. Oh well.... This is probably a better way to do it to keep with a persistent state vision.
posted by Will at 11:59 AM
0 Comments:
Post a Comment
<< Home