Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-26630

Column size for datastore filename is too short

    XMLWordPrintable

    Details

    • Story Points:
      1
    • Team:
      Architecture
    • Urgent?:
      No

      Description

      Simon Krughoff reported that he was ending up with filenames that were too long for the column definition in the datastore records table.

      Currently the file path is 256 characters but we have lots of directories in the default template and the collection appears twice. A collection can be 64 characters so half the path can be taken up solely by the collection.

      Consider using TEXT for this field rather than going to VARCHAR(512).

        Attachments

          Issue Links

            Activity

            Hide
            jbosch Jim Bosch added a comment -

            Looks good.  I like the solution for how to control this semi-globally.

            Show
            jbosch Jim Bosch added a comment - Looks good.  I like the solution for how to control this semi-globally.
            Hide
            tjenness Tim Jenness added a comment -

            This is a schema change so which number am I meant to be incrementing? Or are we going to try to say that we only really need to change the schema version once per week?

            Show
            tjenness Tim Jenness added a comment - This is a schema change so which number am I meant to be incrementing? Or are we going to try to say that we only really need to change the schema version once per week?
            Hide
            jbosch Jim Bosch added a comment -

            I thought there was a Registry-wide version number we could increment for this kind of change, but now I can't find it.  Maybe Andy Salnikov can.  If not, we should at least think about whether it add one or whether we should just increment the versions of all of the manager implementations in cases like this.

            Show
            jbosch Jim Bosch added a comment - I thought there was a Registry-wide version number we could increment for this kind of change, but now I can't find it.  Maybe Andy Salnikov can.  If not, we should at least think about whether it add one or whether we should just increment the versions of all of the manager implementations in cases like this.
            Hide
            salnikov Andy Salnikov added a comment - - edited

            For the changes in the tables that are controlled by the managers the schema version for corresponding manager needs to be incremented. If there are tables that do not belong to any manager then we need to introduce separate version for those tables (or add a "virtual" manager for those tables). Having one global version in addition to per-manager version is complicated, I'd like to avoid that situation. This particular change is not tied to any specific manager, so it may not be trivial to decide which managers are affected, it may be easier to increment all of them? Or I can look at the schema and give you the list of managers that are affected.

            Show
            salnikov Andy Salnikov added a comment - - edited For the changes in the tables that are controlled by the managers the schema version for corresponding manager needs to be incremented. If there are tables that do not belong to any manager then we need to introduce separate version for those tables (or add a "virtual" manager for those tables). Having one global version in addition to per-manager version is complicated, I'd like to avoid that situation. This particular change is not tied to any specific manager, so it may not be trivial to decide which managers are affected, it may be easier to increment all of them? Or I can look at the schema and give you the list of managers that are affected.
            Hide
            tjenness Tim Jenness added a comment -

            At this point it's probably easier to increment them all and not worry about it too much.

            Show
            tjenness Tim Jenness added a comment - At this point it's probably easier to increment them all and not worry about it too much.

              People

              Assignee:
              tjenness Tim Jenness
              Reporter:
              tjenness Tim Jenness
              Reviewers:
              Jim Bosch
              Watchers:
              Andy Salnikov, Jim Bosch, Simon Krughoff, Tim Jenness
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.