Wedge

The only case that could be made for not flagging it unread is if you already read the later post, then happened to manually merge after the event.

When the new post is made and auto merged, it is new content you won't have seen, so it should be marked unread.

- you can easily split posts into new topics, even after they're been pseudo-merged with others...

- you can answer a sub-post and its parent ID will be easily found, i.e. you can track a conversation's parents more easily.

- doesn't fix database space

- can't easily determine if you want to pseudo-merge your posts, it's all automatic. Maybe we could have a 'merge' field in the message table though.

- if someone posts 15 messages in a row, the entire page will be filled by their pseudo-unique post, and then the next one will be on the following page.

You could do that with existing merged posts if the merge code has been retained.

True, though it would make the actual process of handling threaded replies a lot more complex overall.

The difference on InnoDB isn't particularly significant.

Yeah, that to me is quite a big con; personally if posts are merged, I'd expect them to be treated as atomic units, i.e. as a single post.

Hmm... But you'd have to create new posts to accommodate for that, and you know what happens with old posts that have a higher ID...

I don't see where?

Because it doesn't delete the old post anyway, right? If that's true then the new solution would actually be better...

Are you sure?

Store the original id; when it's reinserted it will take its original place.

With a single post being formed, any threaded replies would also be merged into that branch.

If you retain the two posts, you have to figure out how the final thread would be shown.

To me I think of posts as atomic items and merging double posts does seem logical to make the result atomic.

The whole double post thing isn't just about dealing with the signature and avatar and so on... it's also about keeping it a single post, in terms of management, in terms of replying to it, splitting and so on. I can see the wisdom of being able to split two merged posts, but at the same time I'm not keen on it looking like two posts; if I merge two posts I want one physical post.

Let's just say for now that I'm not against the idea but I'm not entirely sold on it yet.

Oh, that sounds messy to me... How so? [merge id=12345 date=67890]?

Heck, I don't even think we can insert a message ID and set the id_msg manually. It'll always rely on autoincrement

Err... No?

(Whether or not we should show "by Nao" on Post 4 in threaded view is something we'd decide later on, depending on the layout and design.)

I'd like to know our users' opinion on this.

We can always add a profile setting to view posts as a single one, as a series of separate posts, or as an in-between version with posts merged together but all buttons available for all posts.

Yes you can, it works as you'd expect: supply an id and it'll use it, don't supply it and you get the benefit of auto-increment.

If you merge posts 1 & 2, surely you'd end up with:
Post 1 & 2 by Arantor
  Post 3 by Nao
    Post 4 by Nao

Sure thing :) That's part of the reason I'm not entirely against the idea.

Works for me :)

No...? Because we wouldn't be merging the posts physically. That's exactly the point. If you're in threaded mode, you'll see Post 2 after Post 4 in that hierarchy, and in flat mode, you'll see posts 1 & 2 together.