Skip to content

Issue 52657: LKSM: We shouldn't allow creating sample names that differ only in case. #6820

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 14 commits into from
Jul 10, 2025

Conversation

XingY
Copy link
Contributor

@XingY XingY commented Jul 3, 2025

Rationale

There has been inconsistency when it comes allowing case sensitive duplicate sample/data names. With this PR, duplicate names that varies only in cases should no longer be allowed.

Related Pull Requests

Changes

  • new DuplicateNameCheckIteratorBuilder to check for case insensitive duplicate during insert/import/update/merge
  • check for duplicate case insensitive names during sample/data in QUS._update
  • Deadlock as result of aliquot rollup calculation and search indexer. Process rollup samples in ascending order to match that of indexer, to reduce deadlock

@@ -212,9 +214,14 @@ public Map<Integer, Map<String, Object>> getExistingRows(User user, Container co
if (!container.getId().equals(dataContainer))
throw new InvalidKeyException("Data doesn't belong to folder '" + container.getName() + "': " + key.getValue().values());
}
// sql server will return case-insensitive match
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how this comment relates to the lines below since there's nothing that says case-sensitive or -insensitive to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated comment to explain why we need to do a java equals check after sql =

return hasNext;

Map<String, Object> existingValues = getExistingRecord();
if (existingValues != null && !existingValues.isEmpty() && existingValues.get(NAME_FIELD).equals(newName))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be equalsIgnoreCase?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, if the case is different, we need to check if renaming is allowed for update and merge. For merge, the work put in is just theoretically at the moment. We don't allow support merge operations that updates names.

.append(tableInfo)
.append(" WHERE LOWER(name) = LOWER(?)")
.add(newOrExistingName);
if (allowExisting) // // exclude existing name for merge
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't we allowing existing names for merge?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated comment

@XingY XingY merged commit aeead5c into develop Jul 10, 2025
14 of 16 checks passed
@XingY XingY deleted the fb_sampleNameCase branch July 10, 2025 21:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants