-
Bug
-
Resolution: Won't Fix
-
Medium
-
None
-
2.4
-
None
As mentioned in the related issue CONF-15539, extranet.atlassian.com's database contained two rows that were almost entirely null, including creation/modification date. At least one of the pages has an attachment. I added the dates in manually, but how these records came to exist is a mystery. We should add not-null to the date columns to prevent this from happening again, but of course such constraints are difficult to add retrospectively. The date on the attachment attached to 1717142914 is Apr 02, 2009, so the bug may have been only in some early 3.0 milestone.
[CONFSERVER-15547] Content rows in database missing required data
Changing affects version to 2.4 (the earliest unarchived version in JIRA at this time), since this bug has been around for the entire history of the product.
I think it would be more appropriate to change the affects version to pre-3.0. I think that it is clearly a bug in the DB schema that these rows can be added. And it's a fixable bug.
The specific rows have already had the dates added.
Purely from a bug wrangling point of view, we should clean up the two affected rows and then close this issue as invalid?
So can we decide on sensible dates for these rows?
> And if the created date is null? I guess we just make a date up?
Or use the oldest date in the system or now?
Well, in that case the created date is already invalid, so there isn't
much choice but to choose a created at that is valid (from the schemas
point of view). I would suggest choosing the epoch or a date similar
(maybe the date atlassian was founded), based on the idea that a row
with a null created at isn't going to sort ahead of rows that do have
a created at.
I've spoken to the user who attached the attachment. She was trying to create a page template with a spreadsheet on it using the editgrid plugin, which has since been discontinued.
And if the created date is null? I guess we just make a date up? Or use the oldest date in the system or now?
But mainly it's difficult because we usually delegate constraint creation to hibernate's schema update tool, and I don't think it creates them. The other option is to create the constraints in an upgrade task that handles the addition of this constraint for every database we support.
Why is it difficult to enforce this constraint for existing datasets? Logically the last modified cannot be null, so if it is, it should be set to the created at date.
Hi Don
Thanks for taking the time to raise this issue. This has been on the backlog for 5 years wit very little movement in that time. Rather than leave this here I'm going to close this out as won't fix, I believe that this better reflects the true status of this issue.
If the problem is raised again in the future we will readdress it.
Regards
Steve Haffenden
Confluence Bugmaster
Atlassian