Témák rendezése
Szerző
Üzenet
Marcee az egyik felhasználó felfedezett egy problémát a phpBB 3.0.12-be.
Azonban a te véleményedre is kíváncsi vagyok hisz azért te csak jobban értesz a mysql-hez
A probléma akkor jelentkezik, ha legenerálok mondjuk 500 témát egy időben.
A fórum-ba lépésnél a lapszámozás hibátlanul jelenik meg, viszont, ha megnézem az első lapot és a második lapot akkor a 2. lapon is kiad olyan témát ami már az első lapon szerepelt.
A sortba rendezés természetesen a beérkezési idő.
A hiba megszűnik amint hozzáadom másodlagosan a topic_id is.
A kérdésem az az, hogy megerősíted, hogy a mysql ebben az esetben hibázhat ill. phpbb bug vagy ez mysql probléma?
A jelenség több szerveren is tesztelve lett és mindenhol ugyan ez a hiba jelentkezett.
Ha azonos az idő akkor a limit 0,25 és limit 25,25 nem tudja melyik volt már és melyik nem!
A kérdéses kód a viewforum.php-ban van:
A hiba megszűnik ha:
ezt
lecserélem erre
Tehát, ha az idő azonos akkor másodlagosan az ID számot veszi figyelembe.
A csapat arra nem gondolt, hogy mi van ha egy időben több téma is beérkezik.
Vagy a mysql-nek tudni-a kéne, hogy mi volt már és mi nem, ha ez így van akkor számos szerver konfig rossz, így én inkább hiszek a phpBB hibában.
Na most várom a te véleményed
Azonban a te véleményedre is kíváncsi vagyok hisz azért te csak jobban értesz a mysql-hez
A probléma akkor jelentkezik, ha legenerálok mondjuk 500 témát egy időben.
A fórum-ba lépésnél a lapszámozás hibátlanul jelenik meg, viszont, ha megnézem az első lapot és a második lapot akkor a 2. lapon is kiad olyan témát ami már az első lapon szerepelt.
A sortba rendezés természetesen a beérkezési idő.
A hiba megszűnik amint hozzáadom másodlagosan a topic_id is.
A kérdésem az az, hogy megerősíted, hogy a mysql ebben az esetben hibázhat ill. phpbb bug vagy ez mysql probléma?
A jelenség több szerveren is tesztelve lett és mindenhol ugyan ez a hiba jelentkezett.
Ha azonos az idő akkor a limit 0,25 és limit 25,25 nem tudja melyik volt már és melyik nem!
A kérdéses kód a viewforum.php-ban van:
Kód:
// Grab just the sorted topic ids
$sql = 'SELECT t.topic_id
FROM ' . TOPICS_TABLE . " t
WHERE $sql_where
AND t.topic_type IN (" . POST_NORMAL . ', ' . POST_STICKY . ")
$sql_approved
$sql_limit_time
ORDER BY t.topic_type " . ((!$store_reverse) ? 'DESC' : 'ASC') . ', ' . $sql_sort_order;
A hiba megszűnik ha:
ezt
Kód:
$sql_sort_order;
lecserélem erre
Kód:
$sql_sort_order . ', t.topic_id';
Tehát, ha az idő azonos akkor másodlagosan az ID számot veszi figyelembe.
A csapat arra nem gondolt, hogy mi van ha egy időben több téma is beérkezik.
Vagy a mysql-nek tudni-a kéne, hogy mi volt már és mi nem, ha ez így van akkor számos szerver konfig rossz, így én inkább hiszek a phpBB hibában.
Na most várom a te véleményed
A fenti kód körülbelül erre a lekérdezésre áll össze (a forum_id változhat):
Ezt, ha phpMyAdminból vagy valamilyen egyéb programból nézed meg, akkor is a fenti viselkedést mutatja.
A MySQL dokumentációjában van két számunkra érdekes bekezdés:
Azaz, ha a LIMIT sorok_szama utasítás ORDER BY-al együtt van használva, akkor a MySQL a sorba rendezést megszakítja, amint megtalálja a lekérdezés rendezett eredményének első sorok_szama sorát (ahelyett, hogy a lekérdezés összes sorát sorba rendezné). Emiatt ugyanaz az ORDER BY-os lekérdezés LIMIT-tel és anélkül más sorrendben adhatja vissza a sorokat.
És itt jön a lényeg: Ha több sorban is ugyanazok az értékek szerepelnek azokban az oszlopokban, amikre rendezünk, akkor a szerverre van bízva, hogy milyen sorrendben adja vissza a sorokat. És ez a sorrend változhat az execution plan (ez egy olyan lista, aminek az egyes lépései azok a műveletek, amikből összeáll a lekérdezés eredménye - ahogy több lekérdezés, úgy több plan is hozhatja ugyanazt a végeredményt) alapján. Vagyis ezeknek a soroknak a sorrendje nem határozható meg egyértelműen.
Emiatt ugyanaz a sor többször is előfordulhat, mint ahogy elő is fordul a fenti esetben.
Ez történhetett
Kód:
SELECT t.topic_id
FROM phpbb_topics t
WHERE t.forum_id = 2
AND t.topic_type IN (0, 1)
ORDER BY t.topic_type DESC, t.topic_last_post_time DESC
LIMIT 0, 25
Ezt, ha phpMyAdminból vagy valamilyen egyéb programból nézed meg, akkor is a fenti viselkedést mutatja.
A MySQL dokumentációjában van két számunkra érdekes bekezdés:
Idézet:
If you use LIMIT row_count with ORDER BY, MySQL ends the sorting as soon as it has found the first row_count rows of the sorted result, rather than sorting the entire result. ...
One manifestation of this behavior is that an ORDER BY query with and without LIMIT may return rows in different order, as described later in this section.
Idézet:
If multiple rows have identical values in the ORDER BY columns, the server is free to return those rows in any order, and may do so differently depending on the overall execution plan. In other words, the sort order of those rows is nondeterministic with respect to the nonordered columns.
Emiatt ugyanaz a sor többször is előfordulhat, mint ahogy elő is fordul a fenti esetben.
KillBill írta:
A csapat arra nem gondolt, hogy mi van ha egy időben több téma is beérkezik.
Nem készíthetsz új témákat ebben a fórumban.
Nem válaszolhatsz egy témára ebben a fórumban.
Nem módosíthatod a hozzászólásaidat a fórumban.
Nem törölheted a hozzászólásaidat a fórumban.
Nem szavazhatsz ebben fórumban.
Nem válaszolhatsz egy témára ebben a fórumban.
Nem módosíthatod a hozzászólásaidat a fórumban.
Nem törölheted a hozzászólásaidat a fórumban.
Nem szavazhatsz ebben fórumban.