Refactoring of data loss system

1 view
Skip to first unread message

Alexander Obuhovich

unread,
Apr 8, 2010, 4:39:22 AM4/8/10
to In-Portal Development
We have data loss prevention system, that consists of several parts (all only in administrative console):
  1. [on by default] Data from tables being edited not directly, but via temporary tables created for each user individually (when user clicks "Add"/"Edit" buttons). When user clicks "Save" button on editing form, then data is copied back from temporary table to original live table.
  2. [off by default] When user clicks "Edit", then we are checking, that given record(-s) is not being edited by another user already and we are showing warning message to the user about that, so he can immediately cancel editing to prevent possible data loss
  3. [on by default] when user clicks "Save" button on editing form we are locking table, so nobody else in that moment couldn't overwrite data user is saving right now

Here I will be talking only about #2 item.

Currently it (#2) is implementing by scanning all temporary tables in database and searching our record ID in them. In case, when there are several administrators adding/editing data all the time, then you will have a lot of temporary tables at the end. Idea of refactoring is to create table, where all items, that are being edited (not added) right now are listed. So instead of database scan we will need only to execute select to that table. Of course we need to add more code to properly update data in that table, so it will be actual in any moment.

Original idea by Sergey.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

Dmitry Andrejev

unread,
Apr 8, 2010, 8:58:05 AM4/8/10
to in-por...@googlegroups.com
Yes, it's a good idea!

Let's create a task for this.

What about release - where do you think it should go in?

Also, I would make sure that TMP tables are properly deleted whenever
Session is gone - should be done by an Agent (running Session
Expiration or may be different one).

DA.

Alexander Obuhovich

unread,
Apr 8, 2010, 9:36:01 AM4/8/10
to in-por...@googlegroups.com
We actually could place SessionKey into that new table, so we delete records by SessionKey, when session got expired.

I don't know what release to put this task into bugfix or feature. In case if bugfix, then 5.0.4 is ok, in case if feature, then 5.2.0 is ok.

Dmitry Andrejev

unread,
Apr 8, 2010, 9:50:45 AM4/8/10
to in-por...@googlegroups.com
I say it's a Feature (improvement) and should go into 5.2.0, plus NOT
that critical now.

Guys?

DA.

Alexander Obuhovich

unread,
Apr 8, 2010, 10:03:13 AM4/8/10
to in-por...@googlegroups.com
Not that critical, I agree.

--
To unsubscribe, reply using "remove me" as the subject.

Phil -- wbtc.fr --

unread,
Apr 8, 2010, 4:22:40 PM4/8/10
to in-por...@googlegroups.com
it's not critical, but it's a really good idea, well explained :)

2010/4/8 Alexander Obuhovich <aik....@gmail.com>

Dmitry Andrejev

unread,
Apr 8, 2010, 11:53:57 PM4/8/10
to in-por...@googlegroups.com
Task has been filed for this (with all specs), but placed in the Future release since there is NO In-Portal 5.2.0 yet (Alex please create).

682: Refactor "Item Open for Editing" mechanisms



DA.
Reply all
Reply to author
Forward
0 new messages