Or you could just hard-code the number as the quotes DB doesn't change very often, and never without you knowing it.
Weren't their plans to create a UI to add and correct quotes?
Do you have problems, concerns or recommendations about the technical side of the Phoenix? Air them here. Compliments also welcome.
Or you could just hard-code the number as the quotes DB doesn't change very often, and never without you knowing it.
Weren't their plans to create a UI to add and correct quotes?
Weren't their plans to create a UI to add and correct quotes?
It's on the list. I liked the current system because it only returns one row, and is neat and precise that way, and doesn't require much knowledge of the details of the quotes in the DB.
I don't want to return a recordset and run through it to a random point -- not every page.
plans to create a UI to add and correct quotes?
I volunteered. Mea culpa. I'll do it right now today if you let me do it non-object oriented! I just have a thing about OO. It's on my list of new year's resolutions along with Vietnamese.
I don't want to return a recordset and run through it to a random point -- not every page.
That's not what that code does though.
It picks a random number between one and the id of the last quote, then gets that quote.
Did the randomisation problem begin when you normalised the data, ita? Like now you're selecting the quote from one table and the ep title from another, right?
The IDs don't have to be contiguous, John -- there's no quote ID 1, for instance. That's why I want the selection to be more tied to the DB.
And I think we have to keep the Phoenix code consistent -- as OO as we can make it.
The data's been normalised since the get go. 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.
The problem began about three weeks ago, IIRC.
I think that's when somebody said something about it. I'd noticed it earlier but... uhhhh... forgot to say anything.
Actually, when it was mentionedby Shawn, someone else said it had been going on for two weeks beforehand. No one else countered her estimation. That's all I have to go by, but it's certainly before the editing and after the normalisation, since it's been normalised since episode numbers were displayed.
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.