[vBulletin] How to fix the 65535-unread-PM-issue (Swedish)

[Tornevall]

Hur lång kan en integer vara?
Jag har ingen koll på det i mitt tillstånd...


(Observera att detta inte är en kuggfråga )

Duke, du kanske vet?

[Tornevall]

Är det måhända ett 10-siffrigt värde?

[Duke]

Det blir dessvärre en kuggfråga... Då det beror på hur många bitar den är på...

Men en sql-"Smallint"... liten integer.. är från -327xx till +327xx....

Jag kommer ju inte ihåg nu vad xx är för siffror.. Men summan blir det de flesta har i antal pm nu.... :| ...

[Duke]

SQL-long, double eller vb/pc/c/j/c++/kob/ - float brukar täcka alla behov och inte längre vara grunden till några problem...

Dock mycket missat.. Men som sagt.. Ha hellre datatyper med mariginaler, det är inte där du kommer ha prestanda-problem längre...


T o m en SQL-boolean har tre värden nuförtiden... jäkla fusk...

0010o

[Tornevall]

Kom precis på det ja, med kuggfrågor.. Fast antalet möjliga poster är långt många fler än 65535 iallafall. Tänk på att vi har nästan 500.000 inlägg skrivna redan

[Duke]

Kom precis på det ja, med kuggfrågor.. Fast antalet möjliga poster är långt många fler än 65535 iallafall. Tänk på att vi har nästan 500.000 inlägg skrivna redan

fast det är knappast något problem.. Att antalet pm hos en enskild forumist inte skulle övergränsa 65000 var nog ett ganska vettigt beslut hos vbulletin programmerarna... Antal inlägg har dock inget med det att göra.., Där kör man en annan datatyp som klarar högre tal...


Det låter nästan som att istället för en rutin för att ta ut max antal pm och lägga till +1 så råkas det ta ut max värde i den datatypen som antal pm har.. mysql har jag aldrig använt men det är nog då = MS-SQLsmallint eller MS-AccessInteger ...

[Tornevall]

Det låter nästan som att istället för en rutin för att ta ut max antal pm och lägga till +1 så råkas det ta ut max värde i den datatypen som antal pm har..

Precis, och här har det diskuterats om att nollställa något värde för att det ska bli bra igen. Det jag frågar mig då är, vilket? Det är det ju ingen som riktigt talar om.

[Duke]

Precis, och här har det diskuterats om att nollställa något värde för att det ska bli bra igen. Det jag frågar mig då är, vilket? Det är det ju ingen som riktigt talar om.

Det lär finnas ett fält i tabellen för "användare" som spec:ar antal pm..

T ex. i User (eller liknande) - tabellen i databasen finns det ett fält som heter 'PMS' (lol... eller liknande) som är smallint eller egentligen.. inte så viktigt...

Att bara nollställa detta kan kanske funka men låter lite läskigt...

Är den någorlunda vettigt uppbyggd, med webanvändning i åtanke, så borde det inte vara några problem att bara nollställa det rakt av.. Kopplingen borde fortfarande finnas mellan id-nummer (systematiskt) på användaren och hans pm...

Så antingen har du ett gränssnitt där du kan nollställa alla värden i det fältet till "0" via en enkel sortering på de > 9000 typ... Eller så kör du en "UPDATE" query där du uppdaterar alla poster med över 9000 till noll.. Om du vill kan jag skriva ut syntaxen åt dig.

Men att tänka på är att det har koll både på antal pm och antal lästa, detta borde dock vara lätt att se ENBART i databasen hur det är löst. Och inga större problem..

[Duke]

Vaffasen, MySQL lär ju garanterat vara som bäst en variant av ACCESS. Och vBulletins databasstruktur lär garanterat finnas offentligt..

Om du har det får du gärna lägga upp det. Annars kan jag kika runt lite imorgon. Lite beroende på hur databasen är byggd så borde det ganska enkelt gå att fixa via en eller i värsta fall två querys.

Däremot är det verkligen märkligt att felet ens kan uppkomma..
Ja,ja.. Imorgon kikar jag gärna upp det iaf..

[Tornevall]

Det lär finnas ett fält i tabellen för "användare" som spec:ar antal pm..

T ex. i User (eller liknande) - tabellen i databasen finns det ett fält som heter 'PMS' (lol... eller liknande) som är smallint eller egentligen.. inte så viktigt...

Nej, det ska vara en global setting för varje användargrupp. Ställer jag in så att medlemmar får skriva 65535 PM så får dom det. Vill man vara sniken bör man alltså kunna ställa in så att olika grupper av användare har möjligheten att posta olika många PM.

Är den någorlunda vettigt uppbyggd, med webanvändning i åtanke, så borde det inte vara några problem att bara nollställa det rakt av.. Kopplingen borde fortfarande finnas mellan id-nummer (systematiskt) på användaren och hans pm...

Det finns ett fält för pmquota i usergroup-databasen iofs, men där står det bara precis 65535.. Däremot finns det faktiskt ett SMALLINT-fält i user som heter pmunread, där bara precis information står om hur många olästa pm dom har.

SELECT * FROM user where pmunread > 65500;

Det här borde alltså i princip gå att göra med automatik, där varje användare själv skulle kunna laga felet...

Men att tänka på är att det har koll både på antal pm och antal lästa, detta borde dock vara lätt att se ENBART i databasen hur det är löst. Och inga större problem..

Gissningsvis använder vbulletin sig fortfarande av sin receipt-kontroll (dvs, den där man kan begära läskvitto) även efter att man stängt av funktionen. Med tanke på att jag faktiskt kan gå in bland mina PM och hitta såna som är lästa och såna som är olästa, betyder det ju att någonstans finns det flaggat att PM'et har blivit läst också. Där finner jag dock en annan svårighet. Den databasen förstår jag mig inte på överhuvudtaget, den är nämligen enbart fylld med siffror.


Duke! Du har nästan löst problemet

[Tornevall]

Vaffasen, MySQL lär ju garanterat vara som bäst en variant av ACCESS. Och vBulletins databasstruktur lär garanterat finnas offentligt..

Tja.. Vi har ju både vbulletin.org och vbulletin.com där jag mer och mer känner att jag har all anledning att börja bli aktiv också. Jag har ju tom två plugins publicerade där redan.

Om du har det får du gärna lägga upp det. Annars kan jag kika runt lite imorgon. Lite beroende på hur databasen är byggd så borde det ganska enkelt gå att fixa via en eller i värsta fall två querys.

Den som jag kollar på ser ut såhär:

 CREATE TABLE  `forum`.`pm` (
  `pmid` int(10) unsigned NOT NULL auto_increment,
  `pmtextid` int(10) unsigned NOT NULL default '0',
  `userid` int(10) unsigned NOT NULL default '0',
  `folderid` smallint(6) NOT NULL default '0',
  `messageread` smallint(5) unsigned NOT NULL default '0',
  `importpmid` bigint(20) NOT NULL default '0',
  PRIMARY KEY  (`pmid`),
  KEY `pmtextid` (`pmtextid`),
  KEY `userid` (`userid`,`folderid`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Där värdet i messageread är det intressanta här.

0 = Unread
1 = Read
> 1 = Inte en aning

I princip skulle koden för min PM-box bli:

$antal_array = $vbulletin->db->query_first("SELECT COUNT(*) from pm where userid = 1 AND messageread = 0");
$antal_olasta = $antal_array[0];
$vbulletin->db->query("UPDATE " . TABLE_PREFIX . "user SET pmunread = $antal_olasta WHERE userid = 1"); 

Däremot är det verkligen märkligt att felet ens kan uppkomma..
Ja,ja.. Imorgon kikar jag gärna upp det iaf..

"På grund av timeout i databasen" har jag också hört folk säga. Men det vetefasen, problemet dök ju upp efter uppgraderingen till MySQL 5.x

[Tornevall]

http://forum.tornevall.net/pmissue.php

Om man sorterat sina PM under olika mappar så är det extra viktigt att man bara läser antalet PM som ligger under folder 0, annars blir allt annat också oläst igen.

$countarray = $vbulletin->db->query_first("SELECT pmunread,userid FROM " . TABLE_PREFIX . "user WHERE userid = " . $vbulletin->userinfo['userid']);
$newcountarray = $vbulletin->db->query_first("SELECT COUNT(*) AS entries FROM " . TABLE_PREFIX . "pm WHERE userid = " . $vbulletin->userinfo['userid'] . " AND messageread = '0' AND folderid = 0");
$newcount = $newcountarray['entries']; 

[Tornevall]

Jaha... Det finns visst en patch också

http://www.vbulletin.com/forum/bugs3...iew&bugid=2432


Edit: Nu bör man kunna gå in i INBOX, markera första sidans PM och välja "Markera som läst" för att få bort det felaktiga antalet. (Jag valde iaf allihopa)
Funkar inte det, så kan man använda pmissue-länken ovan.

[Duke]

queryn: "UPDATE user SET pmunread = 0 WHERE pmunread > 65000" borde ju då iaf fusklösa problemet genom att sätta ner alla med just det felet till 0.. och förmodligen räknas det sedan upp igen som vanligt.

Vill man vara väldigt korrekt så går det ju att göra en join query mot tabellen där själva pm:erna ligger och WHERE satsen istället kör en count på fältet som specar om ett pm är läst eller ej (troligtvis en boolean-flagga) men de är ju lite struligare att formulera. (Du kan givetvis först göra en select sats för att se att WHERE-satsen är rätt skriven innan du ändrar det till en UPDATE.. alltid en bra idé)

CREATE TABLE scripten bör du givetvis vara tokförsiktig med eftersom de försöker skapa (om) tabellen och alla data i den lär försvinna om den lyckas forcera igenom det.

[Tornevall]

queryn: "UPDATE user SET pmunread = 0 WHERE pmunread > 65000" borde ju då iaf fusklösa problemet genom att sätta ner alla med just det felet till 0.. och förmodligen räknas det sedan upp igen som vanligt.

Såg du min lilla patch då, som räknar om antalet olästa PM i huvudboxen?

Vill man vara väldigt korrekt så går det ju att göra en join query mot tabellen där själva pm:erna ligger och WHERE satsen istället kör en count på fältet som specar om ett pm är läst eller ej (troligtvis en boolean-flagga) men de är ju lite struligare att formulera. (Du kan givetvis först göra en select sats för att se att WHERE-satsen är rätt skriven innan du ändrar det till en UPDATE.. alltid en bra idé)

Du menar att hela queryn görs i ett enda svep?

CREATE TABLE scripten bör du givetvis vara tokförsiktig med eftersom de försöker skapa (om) tabellen och alla data i den lär försvinna om den lyckas forcera igenom det.

Ja, createn var till dig bara..