Topic deletion

[Eelke]

I'm no expert with the phpbb3 backend, but would it really be much harder than simply adding a new status to the first post in the topic.

Did you read the topic? No, it would not be hard, what makes you think it is? Several solutions have been discussed in this very topic.

Now, adding it yesterday rather then today is a completely different matter. phpBB 3 has been in development for several years. The developers have, quite rightly, put the product in feature freeze quite some time ago, concentrating on finishing a product with a given feature set, instead of continuing to add on features of which implementing is "really not much harder than..." (fill in the dots to your desire). This latter is commonly called "feature creep" and is one of the traps a project can fall into; adding nice features to the base all the time, (and with every new feature, bugs as well) without ever getting to a finished release. People keep saying phpBB 3.0 can't compete with other board packages with the current feature set. Well, that's to be seen, but one thing is certain; without a release, it can't begin to compete

Acyd Burn said in this topic soft deletion is on the cards for 3.2 release. There's just the "minor" matter of getting 3.0 out the door first.

You might want to increase the size of your last paragraph there. A short reaction: a pluggable architecture as opposed to MODs is the subject of different discussions here on Area51. I suggest you find them, and read them, and possibly add there whatever you have to say after having read some other points of view. Let's not go off-topic here.

[jimmygoon]

I'm no expert with the phpbb3 backend, but would it really be much harder than simply adding a new status to the first post in the topic.

Did you read the topic? No, it would not be hard, what makes you think it is? Several solutions have been discussed in this very topic.

ahh man this i get the feeling is going to take some time.....

and the fact that no one else in this thread mentioned anything about changing the status of the post. Everyone was talking about adding new fields, moving/saving the data and other more complicated methods, if I'm not mistaken.

[edit] I am. Code Reader proposed that idea in the middle of the second page. My mistake. [/edit]

[Eelke]

One reason for talking about new fields (as mentioned above by Lastof) is that for the time being, this would have to be implemented as a MOD. Generally, when doing a MOD, it should be avoided to change the usage of standard database fields to avoid problems with database conversions for new releases.

[code reader]

One reason for talking about new fields (as mentioned above by Lastof) is that for the time being, this would have to be implemented as a MOD. Generally, when doing a MOD, it should be avoided to change the usage of standard database fields to avoid problems with database conversions for new releases.

beg to differ here.
practically, every "normal" (that is, outside the code that specifically approves/disapproves posts) query of the post table contains the AND post_approved = 1 or a variant (eg., AND p.post_approved = 1).
(just a side here: this is somewhat poor programming practice: the "1" should have been some enum, eg. POST_APPROVED, but this is besides the point).
adding a new status, namely POST_SOFT_DELETED (let say, 2) would not require you to touch hundreds of places.
otoh, if you add a new column, you'll have to modify dozens of places and add AND post_deleted = 0 or such to all those queries.
hence, a MOD that overload the existing filed will have to change far less code than a MOD that will add a new column. imo, significantly less code easily trumps "keeping the db pure".
what's more, any other MOD that will query the posts table, will have to contain this AND post_approved = 1 part in it's "where" clause, so overloading this field will significantly increase the mod interoperability with (almost) any other mod that's going to query the posts table (exceptions are MODs that modify the approval mechanism).

if i was to write such a "soft delete" MOD (not likely), i would no doubt overload this column rather than add a new one.

in the above i related to the "post_approved" column in the posts table, but the exact same logic and consideration applies to the "topic_approved" column of the topics table.

peace.

[A_Jelly_Doughnut]

Not all of the databases phpBB uses support enums. IIRC Postgres does not. They could use some sort of character/text field, but integer comparison is faster than string comparison.

[Eelke]

beg to differ here.

Sure, I wasn't putting this down as a end-all statement. I was talking about this more in general terms (like I expect lastof was when he first made this argument), not so much within the context of this particular problem. The only implication, really, is that changing how existing fields are used needs to be carefully considered for the reasons stated. If in this particular case this consideration is proven to not really apply, that's fine. That means we're carefully considering it

Not all of the databases phpBB uses support enums.

Doesn't need to be the database. Could have been a definition somewhere in the PHP code. What code reader is saying is a classic example of magic numbers