1. Tudásbázis
  2. Modulok fejlesztése
  3. bug report

bug report

Beküldte gdavid - 2008. március 6. 12.24
gdavid képe

tobb mint 6 hete bekuldtem a drupal.org-ra egy postgres erzekeny bugreportot patch-el egyetemben.
http://drupal.org/node/212878 es http://drupal.org/node/213212
a mai napig nem tortent elorelepes vagy barmilyen reakcio az ugyben.
vajon rosszul kuldtem be? rossz helyre? mit kene maskent csinalni?

elore is koszi a valaszokat.

Fórum: 
Modulok fejlesztése
Pasqualle képe

Beküldte Pasqualle - 2008. március 6. 17.51

a bug jelentes jo helyen van, csak szerintem senki nem foglalkozik vele
mert a problema es a megoldasa sem vilagos. masik dolog, hogy kevesen hasznalnak postgres-t.

1. szerintem a drupal-6.x-dev hez rossz patchet toltottel fel. (es mindig a 6.x-dev a legfrissebb verzio, nem a 6.1)
2. tolthetnel fel hozza egy screeshot-ot, mert nem egeszen vilagos, hogy mi a problema
3. miert oldja meg a patch a problemat? eleg durva modositas a select-ben. miert mukodik mysql alatt es miert nem megy postgres-ben? nem latok a patchben semmi adatbazis specifikus dolgot.

szoval inkabb bovebb info "up"-olas helyett. az segit..
masfel honap drupal hibajavitas idoben merve nem is sok :)

0
0
gdavid képe

Beküldte gdavid - 2008. március 6. 18.45

az 5.x-esbe eleg rendesen leirtam. jobban megfogalmazni sajnos nem tudom. az egesz problema a ket db kodtablaja miatt van. az egyikben a . megelozi a szamokat a masiknal nem. azert az sql-be beszurni a "AND pid=0" semmilyen kovetkezmenyekkel nem jar a mysql szempontjabol, ellenben pgsql-ben meg javitja a problemat. a masik, hogy kepernyokepet nem igazan tudok mellekelni, maximum adatbazis kodsorokat, azt pedig megtettem.

0
0
Pasqualle képe

Beküldte Pasqualle - 2008. március 6. 19.20

Igy mar ertheto mi a hiba forrasa, es mit probalsz bizonyitani a
select 'abcdef/' < 'abcdef.00.00.00.00/'
selecttel, de ezt biztosan nem talaltam volna ki a issue leirasodbol.

ugy tudom az adatbazisokban megadhato az abc sorrend. de ettol fuggetlenul a hibat akkor is javitani kellene.

ha le tudnad irni a legegyszerubb lepeseket a hiba eloallitasara (foleg, hogy milyen sorrend szerint mukodik nalad a max fuggveny), akkor valakinek biztos felkelti az erdeklodeset, hogy letesztelje a javitasod.

(nem szulettunk gondolatolvasonak. sajnos vagy szerencsere?)

0
0
gdavid képe

Beküldte gdavid - 2008. március 7. 09.06

megprobalom leirni miert nem lehet egyszeruen par lepesbol hibara futtatni vele.
de
hozzal letre egy forumot.
es kezdd el hozzaszologatni.
legyen par 4-5-6 szintu szal.

namarmost amig az embernek csak par foruma es par viszonylag keves szamu commentje es comment szalja van addig nincs is nagy lathato problema.

De a hiba nem egyik pillanatrol a masikra bontakozik ki.
ugye a commenteknek van egy thread-je, ami karaktersorozat, es php inkrementalja az erteket, mert van benne betu is.
namarmost ez normalis esetben a thread ugy nez ki hogy
az alap hozzaszolas XXXXXXX/ formaju.
erre erkezett valaszok XXXXXXX.00/ XXXXXXX.01/ ....
a XXXXXXX.00/ -ra erkezett valaszok pedig XXXXXXX.00.00/ , XXXXXXX.00.01/ .. es igy tovabb

namarmost mikor pg-ben megkerdezik, hogy egy adott node id-je (nid) eseten mi a legnmagyobb thread (uj hozzaszolas eseterol van szo), akkor o megmondja, hogy ez az XXXXXXX.00.01/
mert

# select '123456/' > '123456.01.01/';
 ?column? 
----------
 f
(1 sor)
# select 'a' > '/';
 ?column? 
----------
 t
(1 sor)
# select 'a' > '.';
 ?column? 
----------
 t
(1 sor)
 
# select '0' > '.';
 ?column? 
----------
 t
(1 sor)
 
# select '/' > '.';
 ?column? 
----------
 f
(1 sor)

mint latjuk a fentiekbol az alfanumerikus karakterek nagyobbak a '/' vagy a '.' jelnel. innentol foggva meg mar a '.' es a '/' harcarol beszelunk, amit viszont a PG eseteben mint a .org -on is irtam, a '/' rovasara a '.' nyer, mert neki -47 mig a '/'-nek -48 a kodja.

de a nekunk ez miert is jelent problemat?

azert, mert a comment.module kovetkezo par sora a hiba masodik oldala.

          // Strip the "/" from the end of the thread. 
          // levagja a sor vegerol a '/'-t
          $max = rtrim($max, '/');
 
          // Finally, build the thread field for this new comment. 
          //vissza es atalakitja a kodot mikozben emel rajta egyet. *
          $thread = int2vancode(vancode2int($max) + 1) .'/';

na, a * resznel kovetkezik be a hiba, mert a vancode2int fv egy olyan boduletes nagy szamot alkot azokbol, amiben '.' van hogy csak lesel, mikozben az int2vancode visszalakitja, mar olyant kapsz/kaphatsz, ami meg mar van. mikor pedig kicsit lejjebb beszurja mar kesz is a baj. hiszen minden valasz ami a multiplikalt threadekre erkezik, a rendszer egymas ala pakolja.
helytelenul, igy pedig osszekeverednek rendesen a valaszok amennyiben beagyazott nezeteket valasztanak. (megjegyzem nana hogy osszekeveri oket, mert thread alapjan rendez ez 15, 20, db ugyanolyan thread elmeletileg nem lehetne, pedig van a multiplikacio kovetkezteben)

megprobaltam eleg jol osszefoglalni. igy ezek keletkeznek... ami elmeletileg nem lehetne.

 count |                 thread                  
-------+-----------------------------------------
   706 | 5v4k5zt/
   321 | 5yfchgz/
   254 | 55e37z3/
   215 | 00/
   200 | 5qevegz/
   188 | 01/
   153 | 02/
   133 | 03/
   111 | 04/
    91 | 05/
    77 | 06/
    68 | 07/
    65 | 5dndhxd/
    64 | 55hti3j/
    60 | 08/
    52 | 09/
    49 | 0a/
    48 | 0b/
    48 | 5ohyntz/
    45 | 0c/
    45 | 5xv81zt/
...

ellenben ha csak azok kozott keressuk a maximum-thread-et amiknek nincs pid (parent id) -juk akkor mind a pg mint a my jol csinalja.

0
0