Anope Bug Tracker - Anope Development (1.9.x series)
View Issue Details
0001493Anope Development (1.9.x series)Nickservpublic2013-03-16 12:152013-03-17 03:13
CuttingEdge 
Adam 
normalminoralways
resolvedfixed 
x86_64Ubuntu Linux12.10
 
 
0001493: MySQL NickAlias duplicates
Not too sure if this is a bug or not, but I'm seeing duplicate rows (besides the 'id', 'timestamp' and 'last_seen' fields) in the NickAlias table within MySQL. All the other data is identical. Am I not right in saying there should only be one unique 'nick' in the table?

The 'timestamp' offset between duplicate rows is approximately 30 minutes, so it may take a while to become apparent.
1) Load 'db_sql' while Anope is running concurrently to primary (flatfile) database module.
2) Allow time for duplicates to be created (seems to spawn every 30 minutes).
3) Use: select * from NickAlias where nc = 'nickname';
Using flatfile database as default. Loaded 'db_sql' concurrently to transfer data to MySQL for external (web) queries.

Using latest Anope 1.9.9 GIT.
No tags attached.
Issue History
2013-03-16 12:15CuttingEdgeNew Issue
2013-03-16 13:03CuttingEdgeNote Added: 0006402
2013-03-16 13:24CuttingEdgeNote Added: 0006403
2013-03-16 13:52CuttingEdgeNote Added: 0006404
2013-03-17 03:13AdamNote Added: 0006405
2013-03-17 03:13AdamStatusnew => resolved
2013-03-17 03:13AdamResolutionopen => fixed
2013-03-17 03:13AdamAssigned To => Adam

Notes
(0006405)
Adam   
2013-03-17 03:13   
The main issue here is the fact db_flatfile is what is loading objects on startup. It does not associate ids with objects, so when db_sql sees the id-less objects created it interprets them as being new objects.

This should be fixed in 810685cb739dc32690bd571492629293b4a0e1fd.

You will likely have to mass drop SQL and reimport.
(0006404)
CuttingEdge   
2013-03-16 13:52   
Tested NickServ AJOIN too. Looks like an entry is added to AJoinEntry when I add one via NickServ, but it isn't removed should I delete it almost afterwards.
(0006403)
CuttingEdge   
2013-03-16 13:24   
Seeing duplicates in ChannelInfo too. Only fields changed are the 'id' and 'timestamp' fields. Rest of the data is identical.

Surely the unique key should be the 'name' field? This will prevent such duplicates. Perhaps update the table instead of inserting a new row where the key (add 'name') is a duplicate?
(0006402)
CuttingEdge   
2013-03-16 13:03   
Seeing duplicates within ChanAccess too. Only fields changing are the 'timestamp' and 'last_seen' fields. Rest of the data is identical.