On Wed, Jun 01, 2011 at 11:09:48AM +0200, Varadi Gabor wrote: > > > On Wed, Jun 01, 2011 at 11:03:38AM +0200, Janos SUTO wrote: > > Köszönöm a választ, már is fogalmazom a további kérdéseket :)
Csak a bayes.c -ben találtam hivatkozást a group_type-re :)
ami érdemleges..
**** float bayes_file.... függvény:
- /* query message counters */ -néj jó a az sql select:)
- /* check if sender is autowhitelisted */ -on belül
if(cfg->enable_auto_white_list == 1){ ...a blokk kezdete...
#ifdef HAVE_MYSQL
snprintf(buf, MAXBUFSIZE-1, "SELECT nham, nspam FROM %s WHERE token=%llu
AND (uid=0 OR uid=%ld)", SQL_TOKEN_TABLE, APHash(state->from), sdata->uid);
#endif
A fent selectben akkor is benne van az (uid=0 OR ...) vizsgálat, amikor a
group_type == GROUP_SHARED!!
Ez szerintem nem jó, mert ha csak a uid=0-nál találja meg és a
uid=USER_ID-nél nem, akkor FALSE lesz az adat.
Ugyanúgy az itt meghívott függvénynél qry_spaminess(sdata, state, 1, cfg);
sem lesz jó sdata->uid !!
Csak a függvény végénél (bayes_file függvény) mented el a
saved_uid = sdata->uid és számolod a spamértéket.
Egy hangos kérdés :)
Ha group_type == GROUP_MERGED, akkor nem kellene a tokeneket a t_token
táblába IS beletenni uid=0-val és a hozzá tartozó t_misc táblába IS?
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.
Az updateTokenTimestamps -nál ha group_type == GROUP_MERGED, akkor a
uid=0-ás tokeneknek is állítja az időpillanatát.
Csatolnák 2 fájlt tömörítve, amiben az SQL utasítások vannak benne.
A konfigurációban ami lényeges.
* group_type=0
* initial_1000_learning=1
* update_tokens=1
Mind a két alkalommal ugyan az a levelet küldtem be, unix_uid := 1000-es
felhasználóval a spamdrop-nak.
--
[Varadi Gabor]
sql_1000_1.txt.gz
Description: Binary data
sql_1000_2.txt.gz
Description: Binary data
