The IDs don't have to be contiguous, John -- there's no quote ID 1, for instance.

OK, didn't know that.

we have to keep the Phoenix code consistent -- as OO as we can make it

Fair enough. I think I should read a good book about Object-Oriented PHP, or Object-oriented anything, really, try to get my head around it.

The problem began about three weeks ago, IIRC. There had been no changes to data, table structure, or code at that time. I didn't fix the quote until afterwards.

How weird.

The thing that strikes me is that it's the shortest of all possible quotes, isn't it? I wonder if that has anything to do with it? Short quote, short charactername, short title.

Or, another idea, maybe the server has some kind of caching thing going on where the same request gets cached, and, despite the fact it has "random" in it, it is in some sense the same request for a quote every time?

Yet another thought -- why don't we delete that quote from the DB and see what happens?

How often are people getting it? I'm about one in ten ... which doesn't lend itself to the caching explanation.

I can certainly delete it.

I can certainly delete it.

I'd be interested to see if another one took it's place.

How long is it:

it's all about the coat. Host 'Judgement'
12345678901234567890123456789012345678901

it's 41 chars long.

If we delete it and another very short one starts to show up a lot, then there's a clue, maybe.

And, it's not like we don't all know that quote off by heart by now. It won't get forgotten...

Edited because 31 and 41 aren't the same thing.

And we can always re-add it. I'm curious to see what happens as well.

I've flipped the approved switch to "N", so it should no longer show up.

A quick test brings up a lot of "We die horribly and painfully, you go to hell and I spend eternity in the arms of baby Jesus. Gunn, 'There's No Place Like Plrtz Glrb'"

I just got that one on 4/7 refreshes.

[edit: And, FWIW, every time Read New has sent me to the Message Center in the past few minutes has given me that Gunn quote. Don't know if that's relevant, or just coincidence.

And it's a Gunnathon here, too. Hmm. Plus two Mayors.

It likes the first quote in the table more than it likes all the rest.

Me, I don't really care. I'll toss a seed in and see if anything changes.

I'm researching this in newsgroups, and you know how you said you didn't want to get all the rows and then throw them all away?

That's apparently what it's doing anyway.

"Gavin M. Roy" <gmr@justsportsusa.com> writes:
 SELECT * FROM poetry ORDER BY random() LIMIT 1;
 [ is slow for 35000 rows ]


Yeah.  Basically this query is implemented as
  (a) select all 35000 rows of "poetry";
  (b) compute a random() value for each row;
  (c) sort by the random() values;
  (d) take the first row, discard the rest.


The good news: this gives you a pretty-durn-random selection.  The bad
news: you didn't really care about choosing a random ordering of the
other 34999 rows, but it computed one anyway.


This problem's been discussed before, but I've not seen any really
ideal answer.  SQL is not designed to offer unpredictable results ;-)