React vindt nieuw bericht 4 weken oud :)

Ik post net een bericht in een thread die vandaag loopt:
EfBe in "Alleen een datawarehouse of ook data mar..."

en de titel van het bericht is rood. Als ik er overheen hover meldt de tooltip dat het bericht 4 weken oud is. Erm... nee, het is net gepost

Firefox 1.5.0.8.

(edit). Nu is hij wel goed nu ik de thread opnieuw open. Wellicht klein bugje in react ergens. Ik zie dit voor het eerst overigens.

EfBe wijzigde dit bericht 15-11-2006 11:01 (18%)

renamed 'react' naar 'tpl'

uhm, {message_oldage} wordt toch echt door React bepaald...

Is het geen toeval dat de merge ook iets van 4 weken geleden was? Oude cookie misschien?

crisp wat print/doe je dan precies in de tpl?

code:

<a href="{message_link}"
   {message_oldage && (topic_status == "Open" || topic_status == "Closed") && message_replywquotelink?} class="oldage" title="Bericht is meer dan 4 weken oud!"{;}
>Geplaatst op {@fmessage_date}{message_date_timestamp}{/fmessage_date}</a>

Waar berekent React die message_oldage? Is dat toevallig aan de hand van de webservertijd+F_Messages.Date ?

In dat geval loopt er gewoon een webserver ff uit de pas iets wat af en toe kan gebeuren bij het rebooten van die dingen Wat zichzelf vrij snel weer uit zichzelf opgelost moet zijn.

Een webserver loopt geen 4 weken uit sync toch?

In theorie niet, maar laatst was Aeolus wel aardig de weg kwijt op dit gebied. Uitsluiten zou ik het in ieder geval niet

React doet inderdaad time() - F_Messages.Date > 4*7*86400

dat is:
((".engine::time()." - [TABLE].Date) > 4*7*86400 ) as [PREFIX]oldage
en engine::time() is gewoon een time() met een static var die altijd dezelfde tijd teruggeeft. Hoe dat dan verkeerd kan zijn ontgaat me een beetje...

(fyi: 4 * 7 * 84600 is natuurlijk 28 dagen/4 weken)

Je controlleert de tijd van de insert t.o.v. de huidige tijd (volgens de webserver), en dat kan soms dus foutgaan als er een webserver ff de weg kwijt is zoals ik hierboven al zei

Niet echt een fout in de code, al zou je natuurlijk de tijd uit de db kunnen nemen i.p.v. de webserver, maar dan zou je dat bij een insert ook moeten gaan doen om consequent te blijven.

toch vreemd dat php een negatief getal dan ziet als zijnde > 4*7*86400

nou, mysql ziet dat he, die voert die code uit per-record, alleen die time() komt uit PHP

En now() oid gebruiken is een idee, maar de tijd kan ook gewoon goed staan op de server

Ik neem aan dat bewust time() is gebruikt vanwege cacheability?

Hmm, ik wilde net deze bug gaan posten en had een screenshot gemaakt, en nu zie ik dat er al een topic voor is. Nouja, om het blurren van die screen niet voor niks te laten zijn geweest...
Screenshotje

edit:

Overigens: "Served by Alectrona"

NMe wijzigde dit bericht 27-11-2006 02:40 (8%)

Mocht het zin hebben dit te melden:
Ik heb er ook last van

Zo niet:
Ik zeg niets...

raar hoor, ok, die bak loopt 2 minuten achter ofzo, maar dat mag niet uitmaken.

Same shit.. click

En ik kan me herinneren dat ik het een week of 3 a 4 ook al een keer gehad heb. Na een refresh is het wel goed, en het is ook niet bij elk bericht dat ik post. Waarschijnlijk lastig dat het niet permanent gebeurt, maar helaas

edit:

edit1:
Wat zeg ik, nu doet ie het ook

edit2:
En nu (na de edit) weer grijs

BreadFan wijzigde dit bericht 27-11-2006 08:29 (13%)

quote:

moto-moi schreef op maandag 27 november 2006 @ 07:56:
raar hoor, ok, die bak loopt 2 minuten achter ofzo, maar dat mag niet uitmaken.

Misschien een hele domme opmerking, ik heb geen idee hoe react werkt, maar kan het er misschien mee te maken hebben dat de post dan nieuwer is dan de datum op die bak waardoor de controle misgaat?

Het is nu Adrastos die 13 seconden achterloopt...

MySQL werkt nu eenmaal zo dat als 1 van de operands een unsigned integer type is het resultaat ook een unsigned integer is, tenzij je expliciet het resultaat cast:
code:

CAST(".engine::time()." - [TABLE].Date AS SIGNED) > 4*7*86400 as [PREFIX]oldage

Het kan uiteraard nog veel eenvoudiger:
code:

[TABLE].Date <= ".engine::time()." - 4*7*86400 as [PREFIX]oldage

hiermee vermijdt je helemaal negatieve resultaten
of je dan < of <= gebruikt en de aftrekking door MySQL laat uitvoeren of al in PHP moet Parse zelf maar weten

crisp wijzigde dit bericht 27-11-2006 10:52 (69%)

quote:

crisp schreef op maandag 27 november 2006 @ 10:21:
Het is nu Adrastos die 13 seconden achterloopt...

Adrastos liet inderdaad zojuist dezelfde fout zien.

Fixed in SVN