Trashable model items (Wiki, Ticket, etc.)
Piper, Adam
Tickets, etc. are not irrevocably deleted, but are instead held in a
trash area, available to be re-instated.
There are a number of possible solutions we have discussed, with the
example being wiki pages:
1. Versions < 1
Alter the DELETE to be an UPDATE which decrements the version to the
next available number below 1. Alter the SELECT to take only items with
versions above 0.
I attach a diff implementing solution (1) in a rudimentary manner
2. "deleted" column, version skipping
Add a "deleted" column. Alter the DELETE to be an UPDATE which adds
metadata to a "deleted" column which is, by default, NULL. Alter the
SELECT to take only items where deleted IS NULL. Tweak the save() method
to inspect the DB for its next version number, rather than simply using
"self.version += 1" -- allowing versions to be skipped.
3. "wiki_trash" table w/copy-on-delete listener
Create a new table "wiki_trash" containing trashed versions of wiki
pages. Add a listener for Wiki deletion events and insert (with the next
available version in wiki_trash) the page into wiki_trash. Allows the
deletion of wiki page to go through as normal, and does not require
altering of the current SELECT.
What comments do you guys have on the outlined solutions? Is any of them
preferable? Perhaps there is an alternative solution you would like to
discuss?
Best regards,
Adam Piper
_________________________________________
Logica - Be Brilliant Together
Kingston House,
Towers Business Park,
Wilmslow Road,
Didsbury,
Manchester,
M20 2LX,
UK
T: +44 (0) 161 438 8069
F: +44 (0) 161 438 8100
E: adam....@logica.com
www.logica.com
Logica UK Limited
Registered in England and Wales (registered number 947958) Registered
Office: 250 Brook Drive, Green Park, Reading RG2 6UA, United Kingdom
Please help Logica to respect the environment by not printing this email / Pour contribuer comme Logica au respect de l'environnement, merci de ne pas imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei, die Umwelt zu schützen. / Por favor ajude a Logica a respeitar o ambiente nao imprimindo este correio electronico.
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Mitar
On Wed, Aug 11, 2010 at 12:47 PM, Piper, Adam <adam....@logica.com> wrote:
> There are a number of possible solutions we have discussed, with the
> example being wiki pages:
>
> 1. Versions < 1
>
> Alter the DELETE to be an UPDATE which decrements the version to the
> next available number below 1. Alter the SELECT to take only items with
> versions above 0.
Wouldn't it be easier just to negate ID, not to search for next
available number? Delete can be then just one simple UPDATE statement.
This means that information about deletion status would be stored in
highest ID bit.
What suggest that this could be normalized in another field.
> 2. "deleted" column, version skipping
Yes. So this is then just a question: should be normalize or should we not.
For me ID mingling is ugly. It is not conceptually clean concept.
Mitar
Piper, Adam
>
> On Wed, Aug 11, 2010 at 12:47 PM, Piper, Adam <adam....@logica.com>
wrote:
> > There are a number of possible solutions we have discussed, with the
> > example being wiki pages:
> >
> > 1. Versions < 1
> >
> > Alter the DELETE to be an UPDATE which decrements the version to the
> > next available number below 1. Alter the SELECT to take only items
with
> > versions above 0.
>
> Wouldn't it be easier just to negate ID, not to search for next
> available number? Delete can be then just one simple UPDATE statement.
> This means that information about deletion status would be stored in
> highest ID bit.
>
I had considered simply negating the number, however when testing this
solution I found that this resulted in collisions if the same version
number is deleted twice:
Versions: 1, 2
Delete latest version: -2, 1
Edit/Save version 1: -2, 1, 2
Delete latest version: -2, 1, -2 (collision)
The SQL I provided in my suggestion was written specifically to avoid
this kind of situation.
> What suggest that this could be normalized in another field.
>
> > 2. "deleted" column, version skipping
>
> Yes. So this is then just a question: should be normalize or should we
not.
>
> For me ID mingling is ugly. It is not conceptually clean concept.
Perhaps the 3rd option is the cleanest, then?
Regards,
Adam
Christian Boos
I don't think messing with the version number is the way to go.
See also http://trac.edgewall.org/ticket/9222 and in particular my
comment:2.
-- Christian
Piper, Adam
> See also http://trac.edgewall.org/ticket/9222 and in particular my
> comment:2.
>
> -- Christian
Thanks for the feedback Christian, I've amended my patch (attached) to
address the content of that thread. The patch now requires the following
query to be executed against an existing database:
ALTER TABLE wiki ADD COLUMN deleted datetime NULL;
It will then never allow a full deletion of a wiki page. I appreciate
that full deletion might be required in some cases such as spam cleanup,
and based upon feedback from this mailing list I'll try to decide how to
take this forwards. Do you have any suggestions?
I have cross-posted this on http://trac.edgewall.org/ticket/9222
Best regards,
Adam Piper
_________________________________________
Logica - Be Brilliant Together
Kingston House,
Towers Business Park,
Wilmslow Road,
Didsbury,
Manchester,
M20 2LX,
UK
Logica UK Limited
Registered in England and Wales (registered number 947958)
Registered Office: 250 Brook Drive, Green Park, Reading RG2 6UA, United
Kingdom
Mitar
On Fri, Sep 3, 2010 at 10:54 AM, Piper, Adam <adam....@logica.com> wrote:
> Updated patch attached: DB changes done properly and a few extra tweaks
> so that other portions of the code are aware of deleted pages and behave
> appropriately.
How about attachments? It would be great to be able to store them for
admin to recover them.
Mitar