Why would you bring up tablets when I've just emphasized this is for phones?

Also, it's not the resolution that triggers the change, it's orientation. Holding your phone in landscape orientation makes it wide -- like a desktop computer. For tangentially related fun, check out the Noxico screenshot diary in both orientations on a phone and compare it to the view on a desktop computer.

Folded the database into itself even more, removing the Last Post and Started By fields. Then I added them to the actual index page, including direct link ».

I'll update the rarchive when editpost is in.

It's really very simple. We kill the Batman trade several separate update queries for several select subqueries. It roughly evens out, and we lose the risk of update anomalies.

I seriously haven't had to recalculate anything so far, and never will. Unlike in ABXD, which has a script for specifically that purpose.

Even so, I did say "roughly". Trade one thing for one other thing, but which is more taxing for the server: insert/update, which requires changing the table's files and various other kinds of bookkeeping, or a select subquery, which shouldn't make no change at all? And considering how much better the servers have gotten, does all of that even matter?

That's basically what I'm doing already. Even the database tables' field names are adjusted for readability.

Post revisions

The post_text table right now:
parent_post
message
revision
where revision is coupled to posts.last_revision

Suggested format:
id
parent_post
message
and remove posts.last_revision.

WHAT?

Grab the most recent revision for a post (say, #42) by subquery: ORDER BY id DESC LIMIT 0, 1
Grab revision N for the same like this: ORDER BY id ASC LIMIT N-1, 1

So basically grab revisions not by a "revision #" field, but by limit range.

Example:

id parent_post message 66 41 Well, I don't know. 67 42 Your mother sucks cock in Hell! 68 42 Your mother is a classy lady! 69 42 (Mod note: there was an insult here at first) SELECT message FROM post_text WHERE parent_post = 42 ORDER BY id DESC LIMIT 0, 1 --> (Mod note: there was an insult here at first) -- request revision #1 (original), so N = 1 0, 1 SELECT message FROM post_text WHERE parent_post = 42 ORDER BY id ASC LIMIT (N-1), 1 --> Your mother sucks cock in Hell! -- Note the ascending sort order. -- request revision #2 1, 1 SELECT message FROM post_text WHERE parent_post = 42 ORDER BY id ASC LIMIT (N-1), 1 --> Your mother is a classy lady! -- request revision #3 (most recent) 2, 1 SELECT message FROM post_text WHERE parent_post = 42 ORDER BY id ASC LIMIT (N-1), 1 --> (Mod note: there was an insult here at first)

Could probably simplify a little bit if you consider revision 0 to be the original, and not refer to it as a revision at all.

Final assembled query:

SELECT posts.*, (SELECT message FROM post_text WHERE parent_post = posts.id ORDER BY id DESC LIMIT 0, 1) message, (SELECT COUNT(*)-1 FROM post_text WHERE parent_post = post.id) revision FROM posts WHERE whatever

Instead of SELECT * FROM posts LEFT JOIN post_text ON post_text.parent_post = posts.id AND post_text.revision = posts.last_revision.

This is an actual thing, even though there's no "edit post" interface yet.

Needs, bro? I don't think it needs a background.

It's allowed to be boring -- it's a work in progress.

Where "it" is Delta in general.