Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-14701

OSPropertyText table should have the value column set to extremely-long datatype

    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      The property text table should use the extremely-long data type for its value column so that on databases such as Oracle, CLObs are used instead of limited VARCHAR columns.

            [JRASERVER-14701] OSPropertyText table should have the value column set to extremely-long datatype

            @Tom Your SQL looks OK at a quick glance.

            The documentation subtask of this issue links to this page:
            http://confluence.atlassian.com/display/JIRA/JIRA+4.0+Database+Schema+Changes+for+MySQL+and+Oracle

            Which contains SQL to manually update your DB which looks like this:

            ALTER TABLE PROPERTYTEXT ADD TEMPVALUE CLOB;
            UPDATE PROPERTYTEXT SET TEMPVALUE = PROPERTYVALUE;
            ALTER TABLE PROPERTYTEXT DROP COLUMN PROPERTYVALUE;
            ALTER TABLE PROPERTYTEXT RENAME COLUMN TEMPVALUE TO PROPERTYVALUE;
            

            Mark Lassau (Inactive) added a comment - @Tom Your SQL looks OK at a quick glance. The documentation subtask of this issue links to this page: http://confluence.atlassian.com/display/JIRA/JIRA+4.0+Database+Schema+Changes+for+MySQL+and+Oracle Which contains SQL to manually update your DB which looks like this: ALTER TABLE PROPERTYTEXT ADD TEMPVALUE CLOB; UPDATE PROPERTYTEXT SET TEMPVALUE = PROPERTYVALUE; ALTER TABLE PROPERTYTEXT DROP COLUMN PROPERTYVALUE; ALTER TABLE PROPERTYTEXT RENAME COLUMN TEMPVALUE TO PROPERTYVALUE;

            JC added a comment -

            Great!

            On that note Tom, since you are on Oracle and I know you have some issues with GH performance, you should have a look at: GHS-1398.

            Cheers,
            JC

            JC added a comment - Great! On that note Tom, since you are on Oracle and I know you have some issues with GH performance, you should have a look at: GHS-1398 . Cheers, JC

            Tom Miller added a comment -

            Working with 3.13.5

            Used following statement

            CREATE TABLE JIRA.PROPERTYTEXT_TMP AS
            SELECT * FROM JIRA.PROPERTYTEXT
            /

            COMMIT
            /

            DROP TABLE JIRA.PROPERTYTEXT CASCADE CONSTRAINTS
            /

            CREATE TABLE JIRA.PROPERTYTEXT (
            ID Number(18) NOT NULL,
            PROPERTYVALUE CLOB,
            CONSTRAINT PK_PROPERTYTEXT PRIMARY KEY (
            ID
            )
            )
            /

            INSERT INTO JIRA.PROPERTYTEXT
            SELECT * FROM JIRA.PROPERTYTEXT_TMP
            /

            COMMIT
            /

            and modified the EntryModel.xml appropriately, and all is working fine. Going into production tomorrow morning with it.

            Tom Miller added a comment - Working with 3.13.5 Used following statement CREATE TABLE JIRA.PROPERTYTEXT_TMP AS SELECT * FROM JIRA.PROPERTYTEXT / COMMIT / DROP TABLE JIRA.PROPERTYTEXT CASCADE CONSTRAINTS / CREATE TABLE JIRA.PROPERTYTEXT ( ID Number(18) NOT NULL, PROPERTYVALUE CLOB, CONSTRAINT PK_PROPERTYTEXT PRIMARY KEY ( ID ) ) / INSERT INTO JIRA.PROPERTYTEXT SELECT * FROM JIRA.PROPERTYTEXT_TMP / COMMIT / and modified the EntryModel.xml appropriately, and all is working fine. Going into production tomorrow morning with it.

            AntonA added a comment -

            Yes, that's the right item.

            The database will not be updated automatically. JIRA will simply complain in the logs if the existing database column is of different type than the one it expects (i.e. the one defined in entitymodel.xml and the relevant fieldtype file).

            Cheers,
            Anton

            AntonA added a comment - Yes, that's the right item. The database will not be updated automatically. JIRA will simply complain in the logs if the existing database column is of different type than the one it expects (i.e. the one defined in entitymodel.xml and the relevant fieldtype file). Cheers, Anton

            Tom Miller added a comment -

            Is this the item I need to fix?

            <entity entity-name="OSPropertyText" table-name="propertytext" package-name="">
            <field name="id" type="numeric"/>
            <field name="value" col-name="propertyvalue" type="very-long"/>
            <prim-key field="id"/>
            </entity>

            Second, do I have to manually update a column in the database? Will it update automatically. I am about to migrate from 3.12 to 3.13, so I thought it would be a good time to make this change and see how it goes.

            Tom Miller added a comment - Is this the item I need to fix? <entity entity-name="OSPropertyText" table-name="propertytext" package-name=""> <field name="id" type="numeric"/> <field name="value" col-name="propertyvalue" type="very-long"/> <prim-key field="id"/> </entity> Second, do I have to manually update a column in the database? Will it update automatically. I am about to migrate from 3.12 to 3.13, so I thought it would be a good time to make this change and see how it goes.

            Tom Miller added a comment -

            Thanks, I will try that, but something like this needs to be handled sooner then later.

            Tom Miller added a comment - Thanks, I will try that, but something like this needs to be handled sooner then later.

            AntonA added a comment -

            Hi Tom,

            We will not be able to look at this issue in the 3.1x releases.

            At the moment, we are hoping to correct this problem after we ship the next major release of JIRA. If the testing does not show any problems, we may roll the fix into a bug fix release.

            If you need to urgently fix the issue, you may wish to edit the entitymodel.xml in JIRA and change the database type for the column. Please note that I did not test this fix myself, so I cannot guarantee that it will work.

            Cheers,
            Anton

            AntonA added a comment - Hi Tom, We will not be able to look at this issue in the 3.1x releases. At the moment, we are hoping to correct this problem after we ship the next major release of JIRA. If the testing does not show any problems, we may roll the fix into a bug fix release. If you need to urgently fix the issue, you may wish to edit the entitymodel.xml in JIRA and change the database type for the column. Please note that I did not test this fix myself, so I cannot guarantee that it will work. Cheers, Anton

            Is this likely to get fixed in 3.1x of something. If not, I think it is time for us to start looking for a replacement. We need at least project management lite and Green hopper gives us this. This isn't that hard of a fix to make. Lot's of testing, but easy fix.

            This is a BLOCKER for anyone using greenhopper and Oracle.

            Tom Miller added a comment - Is this likely to get fixed in 3.1x of something. If not, I think it is time for us to start looking for a replacement. We need at least project management lite and Green hopper gives us this. This isn't that hard of a fix to make. Lot's of testing, but easy fix. This is a BLOCKER for anyone using greenhopper and Oracle.

            Tom Miller added a comment -

            I am dead in the water as far as Green Hopper is concerned. This is a BLOCKER for me!!!!

            Tom Miller added a comment - I am dead in the water as far as Green Hopper is concerned. This is a BLOCKER for me!!!!

              mlassau Mark Lassau (Inactive)
              anton@atlassian.com AntonA
              Votes:
              10 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved:

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 6h
                  6h