View Issue Details

IDProjectCategoryView StatusLast Update
0001493Anope Development (1.9.x series)Nickservpublic2013-03-17 03:13
ReporterCuttingEdge Assigned ToAdam  
Status resolvedResolutionfixed 
Platformx86_64OSUbuntu Linux 
Summary0001493: MySQL NickAlias duplicates
DescriptionNot 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.
Steps To Reproduce1) 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';
Additional InformationUsing flatfile database as default. Loaded 'db_sql' concurrently to transfer data to MySQL for external (web) queries.

Using latest Anope 1.9.9 GIT.
TagsNo tags attached.



2013-03-17 03:13

administrator   ~0006405

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.


2013-03-16 13:52

reporter   ~0006404

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.


2013-03-16 13:24

reporter   ~0006403

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?


2013-03-16 13:03

reporter   ~0006402

Seeing duplicates within ChanAccess too. Only fields changing are the 'timestamp' and 'last_seen' fields. Rest of the data is identical.

Issue History

Date Modified Username Field Change
2013-03-16 12:15 CuttingEdge New Issue
2013-03-16 13:03 CuttingEdge Note Added: 0006402
2013-03-16 13:24 CuttingEdge Note Added: 0006403
2013-03-16 13:52 CuttingEdge Note Added: 0006404
2013-03-17 03:13 Adam Note Added: 0006405
2013-03-17 03:13 Adam Status new => resolved
2013-03-17 03:13 Adam Resolution open => fixed
2013-03-17 03:13 Adam Assigned To => Adam