[RFC] Post log/record

Note: We are moving the topics of this forum and it will be deleted at some point

Publish your own request for comments/change or patches for the next version of phpBB. Discuss the contributions and proposals of others. Upcoming releases are 3.2/Rhea and 3.3.
User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: [RFC] Post log/record

Post by MichaelC »

imkingdavid wrote:
Rotsblok wrote:
Unknown Bliss wrote:This would be a good feature but there should be an on/off switch, a field saying maximum disk space for old posts, leave blank for unlimited (so it limit how much db space it would use and prune old ones), a button to prune from before a selected date or prune all.
I would not limit the db space that it can use.. I would limit the number of revisions that are store. eg. 0 for unlimited 1 for 1 revision and so on.. Because I doubt that all post are the same amount of db space
Agreed. You could have a max limit of, say... 5 revisions per post. Or even just 2 or something.

I think to add to this would be to give the moderator the ability to not only compare past revisions, but also to restore the post to an older revision (or a newer one, if it's already at an older revision). It could be helpful in some situations. :P
Then the user could choose, if they had unlimited hosting or 10000GB and using 1GB of diskspace it could be set higher than a person using 900MB with 1.2GB.

And also the ability to restore to previous post revisions or once someone had done that put it back to the latest post revision would be useful.

One important note would be for each revision say who made that revision as it could be the user, moderator or admin.
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

code reader
Registered User
Posts: 653
Joined: Wed Sep 21, 2005 3:01 pm

Re: [RFC] Post log/record

Post by code reader »

i am not 100% sure, but i think that the "draft" mechanism could pretty simply be modified.
with "archival" you do not need to have all the details of the original post, only the text, so it makes sense to have it in separate table.
(oh, and i didn't mention but i, too, think it's a brilliant idea).

i do not believe disk or db space is a serious consideration. my understanding is that editing a post is relatively rare occasions. most posts are submitted and stay as is, so this will not affect the space requirements by much.

however, you *do* want to allow moderators removal of archive copies: if a post is edited by a moderator for containing offensive language, for instance, you might want to remove the offensive post from the archive, or have a mechanism to make the archival copy inaccessible to the public.

peace.

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: [RFC] Post log/record

Post by MichaelC »

The post edits system would probably be Staff and Poster only viewable.
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

User avatar
EXreaction
Registered User
Posts: 1555
Joined: Sat Sep 10, 2005 2:15 am

Re: [RFC] Post log/record

Post by EXreaction »

It should be a permission setting to be able to view them all.

ToonArmy
Registered User
Posts: 335
Joined: Fri Mar 26, 2004 7:31 pm
Location: Bristol, UK
Contact:

Re: [RFC] Post log/record

Post by ToonArmy »

code reader wrote:i do not believe disk or db space is a serious consideration. my understanding is that editing a post is relatively rare occasions. most posts are submitted and stay as is, so this will not affect the space requirements by much.
Further to that compression or differencing could be used.
Chris SmithBlogXMOOhlohArea51WikiNo support via PM/IM
Image

code reader
Registered User
Posts: 653
Joined: Wed Sep 21, 2005 3:01 pm

Re: [RFC] Post log/record

Post by code reader »

ToonArmy wrote:
code reader wrote:i do not believe disk or db space is a serious consideration. my understanding is that editing a post is relatively rare occasions. most posts are submitted and stay as is, so this will not affect the space requirements by much.
Further to that compression or differencing could be used.
true, but i do not think it would be cost effective.
to that matter: we could compress *all* the data - also true, but probably not a good idea...

if we are so worried about DB space, the first things we should do is to fix the perverted mysql fulltext indexing (we index everything twice - practically tripling the space requirements instead of simply doubling it - each of the two copies of this index is roughly as large as the posts table), and discourage everyone from using "fulltext native" (roughly 150% as large as posts table).
in most cases much more devastating than keeping edit versions (at least as far as DB size goes).

User avatar
naderman
Consultant
Posts: 1727
Joined: Sun Jan 11, 2004 2:11 am
Location: Berlin, Germany
Contact:

Re: [RFC] Post log/record

Post by naderman »

code reader wrote:
ToonArmy wrote:
code reader wrote:i do not believe disk or db space is a serious consideration. my understanding is that editing a post is relatively rare occasions. most posts are submitted and stay as is, so this will not affect the space requirements by much.
Further to that compression or differencing could be used.
true, but i do not think it would be cost effective.
to that matter: we could compress *all* the data - also true, but probably not a good idea...
I agree that compression is really not something an application should do with such data. If at all the database should do that, the information should be available without first having to load and decompress the data.
code reader wrote:if we are so worried about DB space, the first things we should do is to fix the perverted mysql fulltext indexing (we index everything twice - practically tripling the space requirements instead of simply doubling it - each of the two copies of this index is roughly as large as the posts table), and discourage everyone from using "fulltext native" (roughly 150% as large as posts table).
in most cases much more devastating than keeping edit versions (at least as far as DB size goes).
Personally I'm not worried about db space. However as for mysql fulltext, I'd be happy to see a patch for a new search plugin interface that allows to change the UI. Once we have that I'm all for offering different feature sets in different search backends, including dropping some mostly useless features from mysql fulltext.

code reader
Registered User
Posts: 653
Joined: Wed Sep 21, 2005 3:01 pm

Re: [RFC] Post log/record

Post by code reader »

naderman wrote:Personally I'm not worried about db space. However as for mysql fulltext, I'd be happy to see a patch for a new search plugin interface that allows to change the UI. Once we have that I'm all for offering different feature sets in different search backends, including dropping some mostly useless features from mysql fulltext.
i'm sorry, but creating a patch to fully "plugin-nate" the UI is a bit more than i can afford ATM...
the annoying thing is that i *did* have it more than halfway done (a little more than 2 years ago) but the team was much less open to user-submitted patches than it is now.
i do not criticize or complain - actually the team *was* willing to take community patches (i do take credit for the fact that the built-in backup-restore system in phpbb3 works, unlike the one in phpbb2), but it was not easy.

but in order to fix the double-indexing it is not essential to change the UI - we can support the existing modes with only one fulltext index (post text + post title) instead of 3. the trick is to use match() AND match(), where the first match is on the index, and the second match (only when user says "body only" or "title only") is on a non-indexed field.
mysql is clever enough to get the posts that match the first search term using the index, and filter the ones that do not match the second search criteria out of the results of the first search.

i actually *had* a working patch to do that, but i don't have it any more ( :( ) sorry.
however, it is an "easy exercise left to the reader".

any community member (or team member...) who reads this and wants to take a crack at doing it will help the sub-community of those who use mysql-fulltext tremendously - getting rid of the superfluous indexes not only improve the space requirements by 50% (i.e., new size will be 2/3 of existing), but it will also cut the posting and editing time by half.

peace.

User avatar
Dog Cow
Registered User
Posts: 271
Joined: Wed May 25, 2005 2:14 pm

Re: [RFC] Post log/record

Post by Dog Cow »

ToonArmy wrote: or differencing could be used.
That's the ticket. There's no sense in storing the entire copy of each revision. Even Subversion stores diffs for each revision.

User avatar
naderman
Consultant
Posts: 1727
Joined: Sun Jan 11, 2004 2:11 am
Location: Berlin, Germany
Contact:

Re: [RFC] Post log/record

Post by naderman »

And systems like git store snapshots instead. The problem you get with storing differences is that you actually have to calculate a particular revision based on all the past revisions and the differences introduced in each one. Simply storing the entire post seems a lot more straight forward. As long as it is in a separate table it doesn't become a memory issue, and surely disk space is not the concern here?

Post Reply