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