Anope Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001493Anope Development (1.9.x series)Nickservpublic2013-03-16 12:152013-03-17 03:13
ReporterCuttingEdge 
Assigned ToAdam 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Platformx86_64OSUbuntu LinuxOS Version12.10
Product Version 
Target VersionFixed in Version 
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.
Attached Files

- Relationships

-  Notes
(0006405)
Adam (administrator)
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 (reporter)
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 (reporter)
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 (reporter)
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.

- 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


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker