Entry tags:
Question thread #149
It's time for another question thread!
The rules:
- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)
- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer and in this comment thread.
The rules:
- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)
- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer and in this comment thread.

no subject
Nearly a year later, circling back re: the above thread. My little corner of the web trucked along just fine for awhile, everything functioning as intended, until a system reboot a couple months ago ate a bunch of the comments and posts we've been playing around with.
Initially, I thought it was something to do with memcached and I've been poking at that, but I finally went elbows-deep into the database tables to cross-reference what's still there versus what's been eaten to actually be able to watch comments posting 'live' and I'm finding a bunch are being written into the database tables as " " (no quotes LOL) rather than the actual text. There doesn't seem to be any rhyme or reason as to which ones are going into the database versus which ones are giving the blank text (varying lengths, emojis or not, etc) but a test reboot of the server confirmed that those comments encoded as disappear from live view on the front end while hard-coded comments remain and I'm totally out of ideas for where I can start troubleshooting this.
Any ideas would be greatly appreciated. ðŸ˜
no subject
no subject
no subject
The problem was, in fact, with the database, specifically within the character_set and collation parameters and a mismatch with the character_set_system being utf8mb3 where everything else was utf8mb4/utf8mb4_0900_ai_ci.
Essentially what was happening is the utf8mb3 was causing the garbage/blank character spaces to actually write to the database in lieu of some posted comments/posts - I was able to track that down with watching the database table populate between comments to spot the pattern (it was specifically related to some emojis and iOS "special" characters like curly quotes). All seemed fine on the front end with Memcached masking the issue - they'd post correctly to Memcached but fail in the database, so with restarts - bye bye data.
Thank you again!
no subject