On Wed, Jun 01, 2011 at 12:26:42PM +0200, Janos SUTO wrote:
> Bar szigoruan veve valoban hibas az sql query, de problemat nem okoz,
> mert
> group_type=0-nal az 'OR uid=%ld' nem ad vissza eredmenyt.
#getHamSpamCounters[sql:SELECT nham, nspam FROM t_token WHERE
token=3327909239040519158 AND (uid=0 OR uid=1000)]
#getHamSpamCounters[rows:1]
Itt adott vissza erdeményt, de hogy az uid=0-ra vagy a uid=1000-re az nem
megállapítható. Ennél a select-nél az sdata->uid nem lett 0 hanem maradt az
eredeti értéke, miközben a group_type := 0!
Mert mi van akkor ha jó ideje MERGED üzemmódban megy a rendszer, tehát van
uid=1000-nél adat bőven, de nincs az uid=0-nál.
átállitom a konfigurációt, SHARED-re és akkor meg fogja találni az
uid=1000-nél a rekordokat.
A enable_auto_white_list TOTÁL GLOBÁLIS és nem felhasználónénti ha MERGED??
> Miert? A 'merged' tipusnak pont az a lenyege, hogy a kozos token halmazt
> nem bantjak a felhasznalok, hanem csak a sajatjukat.
Értem.
>> Mert akkor a GLOBÁLIS tábla is tanulódna, legalább a tanulás idejére,
>> vagy az 1000 levélig vagy ha a felhasználó tanítja.
Ez nem volt jó ötlet mondjuk az első 1000 levélig?
>> Az updateTokenTimestamps -nál ha group_type == GROUP_MERGED, akkor a
>> uid=0-ás tokeneknek is állítja az időpillanatát.
>
> Ez feature, nem bug. Ha csak az uid=xxx tokeneket allitana, akkor a
> megfelelo uid=0 tokeneket idovel kitorolne a purge script.
Ez is eszebe jutott nekem is, de megkérdeztem.
--
[Varadi Gabor]
