Opened 15 years ago
Closed 15 years ago
#4175 closed defect (fixed)
Bogus error: user with same id but different name
Reported by: | Daeron | Owned by: | team |
---|---|---|---|
Priority: | critical | Milestone: | |
Component: | Core | Version: | latest |
Keywords: | Cc: |
Description
I just got a DataIntegrityProblemException after downloading some data from the api which contained multiple usernames for a single uid. The area in question is: http://api.openstreetmap.org/api/0.6/map?bbox=25.56741714477539,60.98416240519864,25.582265853881836,60.98861674828902 although there's currently heavy editing in the area so I'll attach the osm-file downloaded by wget here.
Josm declined to use the downloaded data, so this is a major problem which makes it impossible to edit areas that contain multiple usernames for one uid.
This is NOT an error, and should not result in any kind of exception in josm.
Attachments (1)
Change History (5)
by , 15 years ago
Attachment: | userid.osm added |
---|
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Confirmed. From what I have observed, the userid is the only information relevant to the server. As soon as a user changes their username, all requests to the server return only this new username, even for older data.
It seems as if the old username is completely obliterated from the database.
(This only holds for the current API.)
How to get this error?
1) download an area
2) wait until a user in this area changed their username
3) download another area, where this user has also edited
If you want to simulate this error, skip step 2) and open the .osm file in a text editor instead. Replace every occurrence of a certain username by another string.
This error seems unlikely at first, but there were at least 2 people who got it and the likeliness increases for large datasets, old datasets and more user activity.
To deal with this, we shouldn't save a single username per id, but a list of usernames. Then the last known username should be remembered and used for uplaod.
comment:3 by , 15 years ago
AFAIK, the API does not care about what user uid or name is in the data. It will replace that with the user who is doing the upload anyway.
I think it would be just fine to ignore a mismatch of user names for the same ID and simply keep the first name encountered. I believe this happens rarely enough not to cause confusion.
If we want to do more we can keep a list of all names for each uid and display that joined by '/' or so.
comment:4 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
It seems that only that file does not lead to the exception. I was heavily editing the area, and downloaded that area in addition to the other areas I already had downloaded, which lead to the exception and I also tested the file on the same instance after deleting all layers. But when loaded after restart, the exception does not appear.