|Mass modification of journal entry security settings - revisited
||[Aug. 6th, 2002|09:21 pm]
So this discussion may have gone on awhile ago, but I'll bring it back up for some new thoughts/ideas.
I know there would be a certain amount of database hit involved if we allowed users to mass modify their entire journal, say to private or friends only. There would be many entries getting modified at once, and that would be a large hit on the database. I assume this is correct, and that is the current reason why this feature hasn't been implemented and isn't allowed.
What sort of hit would be involved if we provided a page that listen 10/25/50/100 entries at a time and allowed the user to modify those XX number of journal entries security settings at once?
I picture a table/form listing each of the XX entries with its posted date/time, the subject or first 100 characters (however editjournal handles this), and a drop down list. The drop down list will be pre-selected as the entry's current security setting and will list all the available security settings (or maybe just current and public/private/friends).
The user can use the drop down lists on each entry to modify their security settings individually. Or, an option could be on the page to switch all XX entries to a specific security setting.
Once the form is posted, the processor will check each of the XX entries submitted. A check will be made on each entry to see if the old/current security setting is the same as the new setting. If they are the same, no action will be made to the database. If the settings are different, then the security setting will be modified.
The initial page will default to listing the last XX journal entries and will have skiplinks at the bottom and/or top of the page to go back in the journal's history.
I see this as a sorta compromise between not allowing mass changes at all and allowing the entire journal to be changed in one swoop. The limiting of the entries to 100 or less would decrease the load on the database.
I guess the disadvantage of even limiting to 100 is that's still 100 hits to the master database (I think I'm correct in saying that all updates/writes/modifications have to go to the master and not the slaves). Even 100 such modifications could be too big of a hit on the database. I'm not sure though.
So, any useful thoughts out there? I'd be interested in writing this BML page myself. It'll take me awhile, but would be a nice project to work on. Anyone got a name for it? editsecurity.bml does not seem the best name to me. I'd expect something different from a page with that name. And both editjournalsec.bml and editjournalsecurity.bml seem too long.
OK. Let the discussion begin!