LEARN is adding duplicate entries to the DB #420
Comments
function make_learn() |
Ooops, NVM the ID is auto inc. so changing insert to replace has no effect since the key is ID anyway. |
Okay i changed the primary key to the $pattern col. in aiml_userdefined table then i use replace into to avoid an error should one happen. |
What needs to happen here is that the script first needs to see if the pattern already exists, and if so to run an |
Thanks, Im adding the AIML LEARN file to make testing a bit easyier. |
added an IF block around the function |
I found that when i add in an if block that uses a NO MATCH FOUND cond. that it helps quite a lot. |
An example to resolve the problem with following code change in "../chatbot/core/aiml/parse_aiml_as_XML.php" from line 1332 (version 2.6.10):
|
Added for testing, Nice work and better than my ugly hacks. |
Looks great man. Not getting duplication at all now. |
+1 to the changes after doing many tests. It fixes quite a few smaller problems along with making at least ATOMIC LEARNING work right. |
Having duplicates is just fine because thats how |
Humm so at best persistent learn does is remember 1 response to 1 user temporally? |
Each conversation has it's own unique id and if you use learn it will save your pattern, that, template and your conversation id in the table aiml_userdefined. Now when you ask your bot a question it will also lookup the aiml_userdefined table searching for your pattern with the actual conversation id. If you start a new conversation the id will change and your pattern can't be found in future requests. That's the reason why a new entry is insert and you get your duplicates. That's how it works. It will store and find your pattern only for this conversation. If you want to find your pattern anyway we have to implement the learnf tag. Which will ignore you conversation id and prevent you from adding duplicates. I hope now it's clear. :) |
Ok i think i see but for me i would rather it just look for the pattern no matter that convo_id it was or use -1 so it dosent matter and thats what lead to dupes becoming an issue in that it caused a huge amount data to be stored that caused it all to run slow. |
At the moment there is a typo in the function parse_learn_tag. You have to change the following line: // old
$params[':user_id'] = $user_id;
// new
$params[':user_id'] = $convo_id; This is already fixed in your version. ;) |
Okay did that, But still not seeing ANY scores of 300 show up with over 150 added so far to the table (added temp debug to tally score hits). |
BTW if you knew about the typo why dident you commit the change? |
In hacker world id try to tally score 300 hits and save it to a temp file. Once X hits happed then purge the table up to the previous current date and avoid the cron from hell. |
I didn't even know about it a few days ago. At the moment I am on vacation and have time to take care of it. This is also the reason why I found the error so recently. |
fair enough man. |
done with helping! tnx to the cool people, see you on the fork ! |
When it inserts a new learned entry into the user_defined_aiml i find may copies of the same exact data there.
Where would i look in the php that would be checking for an existing entry before it inserts a new one at?
The text was updated successfully, but these errors were encountered: