Y24-316 - As developers we want to increase the size of the id_sample_lims column in the sample table to 255 so we can ensure that sample ids from any other LIMS systems will be stored as we cannot guarantee that it will meet the current limit of 20

[stevieing]

User story As developers we want to increase the size of the id_sample_lims column in the sample table to 255 so we can ensure that sample ids from any other LIMS systems will be stored as we cannot guarantee that it will meet the current limit of 20

Who are the primary contacts for this story Steve / Tom / David / Marina

Who is the nominated tester for UAT Marina

Acceptance criteria To be considered successful the solution must allow:

• [ ] a sample with an id greater than 20 should be stored successfully

Dependencies This story is blocked by the following dependencies:

• sanger/#

References This story has a non-blocking relationship with:

• sanger/#

Additional context Add any other context or screenshots about the feature request here.

[TWJW-SANGER]

Possibly already noted - but worth mentioning that as this is a schema change to a large important table which will lock access during the change, this will need careful handling. Also we should be aware that the UAT environment doesn't test the replication to the read-only MLWH servers - which has caught us out before. The process for handling this is described in MLWH - Guidelines for bulk updates, migrations and performance on Confluence.

Finally - may also be worth checking the size of the table before and after the change in UAT. In my toy tests I couldn't detect any difference between in size or performance between a varchar(30) and varchar(255) on a simple table with a million rows. A quick check that this holds true on the actual platform might be wise.

[stevieing]

Possibly already noted - but worth mentioning that as this is a schema change to a large important table which will lock access during the change, this will need careful handling. Also we should be aware that the UAT environment doesn't test the replication to the read-only MLWH servers - which has caught us out before. The process for handling this is described in MLWH - Guidelines for bulk updates, migrations and performance on Confluence.

Finally - may also be worth checking the size of the table before and after the change in UAT. In my toy tests I couldn't detect any difference between in size or performance between a varchar(30) and varchar(255) on a simple table with a million rows. A quick check that this holds true on the actual platform might be wise.

Already noted. I plan to leave it on UAT for at least a week. I will then deploy to training and not the length of time it takes. I will then liase with DBAs to inform them of what I plan to do just in case we need to drop any connections. I will also do it outside office hours.