1. Tudásbázis
  2. Modulok használata
  3. Hibát találtam?

Hibát találtam?

Beküldte gdavid - 2008. január 18. 22.43
gdavid képe

egy jó ideje fennálló problémát sikerült megoldanom, talán.

a hozzászólásokkal volt kis gondom, de nem tudtam miért.
lehet, hogy a php vagy a szerver a ludas, de a szitu a következő, néha egy nagyobb fórum esetén a mikor a tartalomhoz szólnak hozzá, akkor rossz thread-et ad meg a rendszer.
a comment.module-ból idézek

        // Here we are building the thread field. See the documentation for
        // comment_render().
        if ($edit['pid'] == 0) {
          // This is a comment with no parent comment (depth 0): we start
          // by retrieving the maximum thread level.
          $max = db_result(db_query('SELECT MAX(thread) FROM {comments} WHERE nid = %d', $edit['nid']));
 
          // Strip the "/" from the end of the thread.
          $max = rtrim($max, '/');

ez még szép és jó is lenne, hiszen kikeresi a legnagyobb thread-et egy adott node hozzászólásaiból, akkor ha a comment nem válasz.
          // Finally, build the thread field for this new comment.
          $thread = int2vancode(vancode2int($max) + 1) .'/';

ez pedig az adott thread-et átalakítja számmá, majd megnöveli +1-el és visszaalakítja kóddá.
csakhogy ha a MAX ezt adja vissza pl
* 5joritx.00
és ez átalakítva számmá ezt kapom:
* 1542826109520
amihez ha hozzáadok +1 -et, akkor ezt kapom:
* 1.54282610952E+12
amit ha visszaalakítok kóddá, akkor kapom ezt:
* 5ffe7v5
aminek ellenőrzésképpen az értéke:
* 932850257
megjegyzem hogy a fenti kód már létezik a node-hoz, nem kevésszer.
 uid  | nid | timestamp  |  cid  | pid |  thread  
------+-----+------------+-------+-----+----------
 1061 | 770 | 1200490680 | 20325 |   0 | 5ffe7v5/
 1045 | 770 | 1200491671 | 20332 |   0 | 5ffe7v5/
 1063 | 770 | 1200492265 | 20335 |   0 | 5ffe7v5/
 1073 | 770 | 1200496741 | 20360 |   0 | 5ffe7v5/
 1045 | 770 | 1200497071 | 20365 |   0 | 5ffe7v5/
 1073 | 770 | 1200497233 | 20366 |   0 | 5ffe7v5/
 1045 | 770 | 1200497371 | 20367 |   0 | 5ffe7v5/
 1073 | 770 | 1200497478 | 20368 |   0 | 5ffe7v5/
 1139 | 770 | 1200507781 | 20429 |   0 | 5ffe7v5/
 1073 | 770 | 1200512739 | 20467 |   0 | 5ffe7v5/
 1069 | 770 | 1200528038 | 20568 |   0 | 5ffe7v5/
 1185 | 770 | 1200555702 | 20590 |   0 | 5ffe7v5/
 1130 | 770 | 1200556266 | 20592 |   0 | 5ffe7v5/
 1185 | 770 | 1200563943 | 20611 |   0 | 5ffe7v5/
 1045 | 770 | 1200577482 | 20690 |   0 | 5ffe7v5/
 1045 | 770 | 1200577643 | 20692 |   0 | 5ffe7v5/
 1045 | 770 | 1200577671 | 20693 |   0 | 5ffe7v5/
 1180 | 770 | 1200578608 | 20703 |   0 | 5ffe7v5/
 1045 | 770 | 1200584306 | 20745 |   0 | 5ffe7v5/
    1 | 770 | 1200641028 | 20857 |   0 | 5ffe7v5/
 1095 | 770 | 1200651491 | 20872 |   0 | 5ffe7v5/
 1134 | 770 | 1200651664 | 20873 |   0 | 5ffe7v5/
 1073 | 770 | 1200654066 | 20874 |   0 | 5ffe7v5/
(23 sor)

azt hiszem két dolog segíthet

$max = db_result(db_query('SELECT MAX(thread) FROM {comments} WHERE nid = %d and pid=0', $edit['nid']));

révén, hogy úgyis csak akkor jön ide a feltétel, ha pid=0, akkor meg mit érdekel minket a többi szál hosszú kódja?
a másik pedig
$thread = int2vancode((int)vancode2int($max) + 1) .'/';

amivel kikényszeríthetem hogy kod->szám tényleg olyan szám legyen amit képes feldolgozni az átalakító.

Vélemények?

Fórum: 
Modulok használata
pp képe

Beküldte pp - 2008. január 19. 11.18

Kipróbáltam nekem ment a dolog, úgyhogy valahol máshol van a hiba.

Ha megnézed a comment_render függvényt, akkor láthatod, hogy ott le van írva pontosan hogyan működik a hozzászólás thread képzés és miért.

A lényeg az, hogy olyat nem kaphatsz, max-ként, amiben . van, tehát valamiért rossz értéket kapsz eleve az adatbázisból.

5joritx.00 - ez az érték a 5joritx-szál első hozzászólása, ez a hozzászólás a 1190452245. ami egy nagyon nagy szám, lehet nincs ennyi hozzászólás összesen. ;)

Meg kéne nézni, hogy van-e thread = '5joritx/' az adatbázisban, mert ha nincs, akkor itt lesz a hiba.
Azt kell kideríteni, hogy hogyan jön létre ez a helyzet.
Hogy mitől lehet még gondolkodom, és kísérletezek én is, ha lesz valami szólok.

pp

0
0

Palócz István
https://palocz.hu | https://tanarurkerem.hu

gdavid képe

Beküldte gdavid - 2008. január 19. 17.07

amit nem irtam bele, hogy postgres 8.1-es a DB php5 apach2
es bizony adhat a max fv .-ot tartalmazo erteket, reven hogy a abcdef < abcdef.00.00.00.00

# select 'abcdef' < 'abcdef.00.00.00.00';
 ?column? 
----------
 t
(1 sor)

es ez pedig
$max = db_result(db_query('SELECT MAX(thread) FROM {comments} WHERE nid = %d', $edit['nid']));

nem szuri le azokat, amikben pont van, vagy van pid-je.
0
0
pp képe

Beküldte pp - 2008. január 20. 09.26

Pont ezért van minden thread végén egy / jel, ez nálad nincs ott?
# select 'abcdef/' < 'abcdef.00.00.00.00/';
ennél is ugyan az az eredmény?

Ha igen, akkor a psql-ben nem megy jól ez a dolog. Mysql-ben ez tök jól megy, pont ezért nincs értelme szűrni a .-ra meg a pid-re, mert mindegyik végén ott a / ami nagyobb a .-nál is.

pp

0
0

Palócz István
https://palocz.hu | https://tanarurkerem.hu

gdavid képe

Beküldte gdavid - 2008. január 20. 22.57

Az adatbazis PostgreSQL 8.1
# select 'abcdef/' < 'abcdef.00.00.00.00/';
?column?
----------
t
(1 sor)

postoltam a patch-et a drupal.org-ra is, mert ez a hiba nem csak nalam jelentkezett, volt is tobb megoldas ra, ahol mindenutt csak a hiba kikerulesevel foglalkoztak. (pl a pont-nal szetvalasztottak es csak az elso resszel foglalkoztak)

http://drupal.org/node/97327

pedig helyesebb mukodes szempontjabol azok kozott keresni a maximumot, ahol pid=0

de egy kis ellenorzes nem arthat.
template1=# select '.'>'/';
?column?
----------
t
(1 sor)

template1=# select '.'<'/';
?column?
----------
f
(1 sor)

template1=# select hashchar('.');
hashchar
----------
-47
(1 sor)

template1=# select hashchar('/');
hashchar
----------
-48
(1 sor)
mint innen is latszik a pont nagy, legalabbis nem kisebb mint a /

0
0
pp képe

Beküldte pp - 2008. január 21. 08.13

Ez érdekes. A / nagyobb mint a ., de a psql negatív számokat ad vissza, tehát a sorba rendezés elvileg jó lehet, ha a betűknél és a számoknál is a megfelelő negatív számot adja vissza. Ezt is meg kéne nézni, ugyanis, a per azért van a végén, hogy a sorrend jó legyen, de ha ez nem igaz, akkor az egész úgy ahogy van hibás.

Tehát a rossz kezdő-thread generálását megoldja amit írsz, de azt gyanítom jóval több probléma forrása lehet ez az apróság. (pl. a szálak összekeverednek.)

pp

0
0

Palócz István
https://palocz.hu | https://tanarurkerem.hu

gdavid képe

Beküldte gdavid - 2008. január 21. 13.55

már korábban is jeleztem az összekeveredési hibát itt is, de csak most volt elég energiám kísérletezni vele annyit, hogy rájöjjek a hibára.

# select hashchar('a'),hashchar('á'),hashchar('.'),hashchar('e'),hashchar('é');
 hashchar | hashchar | hashchar | hashchar | hashchar 
----------+----------+----------+----------+----------
      -98 |       60 |      -47 |     -102 |       60
(1 sor)

nem tudom mi alapján rendezi a neveket, meg karakterláncokat, de eddig helyesen csinálta a rendezéseket. kis és nagybetű, magyar karakterek esetében is.
valószínűnek tartom, hogy a fejlesztők MySQL alapokból indultak ki és mint a 2006-os drupal.hu confon is megjegyeztétek a mysql nem éppen korrektül rendezi a nem angol karaktereket utf8-ban, nem úgy mint a pg.

egyébként tény és való, hogy a mostani (nem javított) thread kezelésnek köszönhetően
van néhány multiple-thread-em.

# select count(thread),thread,nid from comments group by 2,3 having count(thread)>1 order by 1 desc;
 count |  thread  | nid 
-------+----------+-----
   254 | 55e37z3/ | 778
    24 | 592oai9/ | 828
    23 | 5oozw7z/ | 790
    20 | 5txvmkv/ | 780
    12 | 5jtu2gv/ | 781
     9 | 551nmqn/ | 815
     8 | 58lndv5/ | 801
     4 | 52k0xk1/ | 776
(8 sor)

emiatt vagyok kénytelen nélkülözni a thread-eket a fórum megjelenítés terén.
azt már meg sem említem, hogy más, roppant zavaró hiba is van a comment kezelésben, már több éve...

és iszonyat jó lenne, ha 6.0-ban a fent közölt javítás is bekerülne és nem kéne a hibás új-verziókat mindig felüljavítanom.

0
0
nevergone képe

Beküldte nevergone - 2008. január 21. 14.30

iszonyat jó lenne, ha 6.0-ban a fent közölt javítás is bekerülne és nem kéne a hibás új-verziókat mindig felüljavítanom.

Nem látom a hibát az issues -ben, pedig szívesen látnám.

a mysql nem éppen korrektül rendezi a nem angol karaktereket utf8-ban, nem úgy mint a pg.

Erről van valahol valami információ? Valószínűleg kell majd készítenem egy portált, ahol a magyar nyelv helyes kezelése (a nyelvi szabályoknak megfelelő sorbarendezés, egybevetés) szükséges.

0
0

Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés

gdavid képe

Beküldte gdavid - 2008. január 22. 12.58

azt meg anno az 5.0 elejen volt, azt hiszem azota javitottak a hibat, mert sehol nem hallottam rola semmit.
de errol goba meselt anno, ha jol emlexem.

0
0
aries képe

Beküldte aries - 2008. január 22. 13.12

Ne az utf8_generic_ci -t használjátok.

Aries
http://aries.mindworks.hu

0
0
nevergone képe

Beküldte nevergone - 2008. január 22. 13.43

Nekem eddig minden Drupal adatbázisom latin1_swedish_ci egybevetéssel működik (phpmyadmin ezt adta alapból), ezek szerint az sem a jobb döntés. Az utf8_hungarian_ci jobban használható a magyar nyelv szabályainak megfelelő egybevetésre? Ezért kérdeztem.

0
0

Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés

aries képe

Beküldte aries - 2008. január 22. 21.11

A Drupal alapból minden táblát utf8_generic_ci egybevetéssel hoz létre. Az adatbázis collation-je Drupal szempontjából mindegy, a tábláké és a táblamezőké viszont nagyon fontos!

Aries
http://aries.mindworks.hu

0
0
nevergone képe

Beküldte nevergone - 2008. január 22. 21.34

Akkor minden Drupal telepítés esetén egyesével állítsam át a táblákat pl. a phpmyadmin segítségével?

0
0

Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés

Illyés Edit képe

Beküldte Illyés Edit (nem ellenőrzött) - 2008. január 22. 21.47

És az egyszerű átállítás nem is elég, konvertálni is kell a tartalmakat. Ezt mindenképpen ajánlott lenne megcsinálnod, mert amíg csak ül a webhelyed az adatbázisban (ami feltehetőleg még a MySQL 4.0 korszakban keletkezett), addig oké, de amint megmozdítod, tönkre fognak menni az ékezetes karaktereid.

Basically, Drupal always uses utf-8 encoding, but MySQL 4.0 and lower doesn't support it, so utf-8 data are treated as default Latin 1 inside the MySQL 4.0 engine. It doesn't matter there, as MySQL output echoes the same data as sent in still, so Drupal works fine, but it matters a lot in the migration process, where MySQL might attempt to "convert" the data from Latin 1 to utf-8, not knowing that we have utf-8 in there already, and so the site gets broken then.

Szerencsére van jó leírás és kész szkript Latin-1-ről UTF-8-ra konvertáláshoz. Mondanom sem kell, előbb biztonsági mentés az adatbázisról, mielőtt ráereszted a szkriptet :)

0
0
nevergone képe

Beküldte nevergone - 2008. január 22. 22.01

ami feltehetőleg még a MySQL 4.0 korszakban keletkezett

Őőőőő... erre akkor is szükség van, ha nem akkor keletkezett? Értem ezalatt, hogy mindenből ötöst használok (PHP és MySQL) kezdettől fogva, így nem tudom, mennyire érinthetnek a MySQL 4.0 furcsaságai?

0
0

Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés

aboros képe

Beküldte aboros - 2008. január 22. 21.47

jó, bár nem értem pontosan, nade ha nem utf_generic_ci, akkor mi legyen a collation -je az adatbázisnak?

0
0

-
clear: both;

aries képe

Beküldte aries - 2008. január 23. 13.24

utf8_hungarian_ci, de nem csak az adatbázisnak, hanem a tábláknak és a mezőknek is. Az összes egybevetés legyen ez.

Aries
http://aries.mindworks.hu

0
0
aboros képe

Beküldte aboros - 2008. január 23. 17.26

és ha többnyelvű az oldal? mondjuk van magyar, angol, német, meg mondjuk még spanyol és török is, csak hogy érdekes legyen?

0
0

-
clear: both;

aries képe

Beküldte aries - 2008. január 24. 15.23

utf8_general_ci , ez az alap. Ha többnyelvű az oldal, akkor a speciális karakterek sorrendbelisége nem biztos, hogy az adott nyelvnek megfelelő lesz. A sorrend kezelése adatbázis szintű, különben nagyon lassú lenne.

Aries
http://aries.mindworks.hu

0
0
pp képe

Beküldte pp - 2008. január 22. 11.43

Az a baj, hogy itt hiába jelzed, azt érdemesebb a nemzetközi oldalon is jelezni.

pp
(különben nem lesz javítva.)

0
0

Palócz István
https://palocz.hu | https://tanarurkerem.hu

gdavid képe

Beküldte gdavid - 2008. január 22. 13.23

angolom nem valami ekes. sokat kopott miota nem hasznalom...
de kitettem az issue-ba.

0
0
gdavid képe

Beküldte gdavid - 2009. július 13. 08.37

jo ideje fenn van az issue a drupal.org -on, de meg mindig hibasan jonnek ki az ujabb es ujabb 6.x -es valtozatok, csakugy, mint a 7.x-dev-ek.

Issue: comment thread IDs grow too fast
http://drupal.org/node/97327
a bekuldes ideje:November 13, 2006 - 16:52

szeretem a drupal-t es ez meg igy is marad. de ez a hiba nem bagatel, maximum azoknak akik mysql-t hasznalnak. nem fogok atallni mysql-re mert nem az a hiba javitasanak modja.

0
0
gdavid képe

Beküldte gdavid - 2008. január 23. 08.22

a problema a 6 rc2-ben is ott van, oda is kuldtem issue-t.

0
0
nevergone képe

Beküldte nevergone - 2008. január 23. 09.54

Talán az éppen aktuális fejlesztői változattal is meg kellene próbálni, nem tudom, hogy mennyire foglalkoznak most a többi issue-bejegyzéssel.

0
0

Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés