[#CONF-7882] Multiple AttachmentData objects were returned when only one was expected

Confluence

Multiple AttachmentData objects were returned when only one was expected

Created: 15/Feb/07 06:03 PM Updated: Thursday 06:21 AM

Component/s:

Attachments, Database / Hibernate

Affects Version/s:

2.3.1

Fix Version/s:

None

Time Tracking:

Not Specified

Participants:	Don Willis [Atlassian], Ivan Benko [Atlassian] and Per Fragemann [Atlassian]
Since last comment:	1 year, 11 weeks, 3 days ago
Internal Complexity:	3
Internal Value:	5
Labels:
Support reference count:	17

Description

« Hide

See https://support.atlassian.com/browse/CSP-7087 for more details and a stack trace.

I was not able to reproduce it by 'clicking the upload button twice' . Yet somehow there are multiple copies of AttachmentData.
(reviewed by Sam)

excerpt from the HibernateAttachmentDataDao.java l.65
// TODO find a more appropriate exception
if (dataObjects.size() > 1)
throw new RuntimeException("Multiple AttachmentData objects were returned when only one was expected");

Question remains - how possible multiple objects were created in the DB initially? Please investigate...

All

Comments

Work Log

Change History

Sort Order:

[ Permalink | « Hide ]

Ivan Benko [Atlassian] added a comment - 18/Feb/07 05:22 PM

Please see the most recent post from Christian Hansen on CSP-7087 [16/Feb/07 05:02 AM]
It seems as a particular ID from the ATTACHMENTS table is not referred in the ATTACHMENTDATA table at all. Instead of that, two copies of the same ID exists there.
User resolved the problem by changing one of the duplicates to an expected value and problem was solved. However, two copies of the same version of an attachment still remained on a page.

[ Permalink | « Hide ]

Per Fragemann [Atlassian] added a comment - 30/Oct/07 03:42 AM

Even though this issue has been assigned and waiting in the 2.5.x queue for a while, there was no immediate necessity to fix it (when comparing it to other issues importance). It has been decided to remove the fix version and reschedule it later.

[ Permalink | « Hide ]

Don Willis [Atlassian] added a comment - 15/Apr/08 03:18 AM

I suggest we add a unique constraint to the attachmentdata.attachmentid column. That would stop this situation happening in any new instances. It might create another bug, since there's presumably an application logic flaw that attempts to insert two data rows for the one attachment, but this bug should be easier to find once the unique constraint causes an exception to be thrown immediately by the second insertion.