yeast genes that have naming patterns not allowed by load network from database function

[kdahlquist]

I've been playing around with the load network from database function to see what happens when I try to find yeast genes that have unconventional naming patterns.

• First, the good news. The 3 genes that had a comma in their standard name and 1 gene that had an apostrophe got renamed! So no problems there.
• However, I've found 2 genes that have parentheses in their standard names, MF(ALPHA)1 and MF(ALPHA)2. If I search for either of those with their parentheses, they trigger the error modal. They are in the database, though, because if I search on them based on their systematic names, YPL187W and YGL089C, they come up properly. I think we are going to need to allow parentheses in the input to that search field so that they will be properly retrieved.
• I did a scan of some old microarray data I had to find these. We should probably scan the data in the database to make sure that there aren't any other oddballs out there.

[kdahlquist]

Just for posterity, here are the genes I tested.

[kdahlquist]

• DUR12 used to be DUR1,2
• IMP21 used to be IMP2'
• ARG56 used to be ARG5,6
• ADE57 used to be ADE5,7

[dondi]

1. Scan gene expression and regulation database
2. Look for IDs with commas, apostrophes, and parentheses—replace with new ones for the above four genes
3. For genes with parentheses, note what appears and pass along to #997 for regex adjustment

After this is done, #997 can then follow

Domain note: We anticipate that these are legacy fixes and future genes, if any, will be made to comply with the stricter naming conventions. Thus, a general solution appears to be unnecessary

[Onariaginosa]

I scanned the database and found that the only genes in our database with unusual names are the following:

Because of this I just created an exceptions object that maps the irregular name to a name that we accept within GRNsight:

This issues should be resolved in PR #996, as I was working on fixes for that simultaneously.

[kdahlquist]

confirmed fixed in beta 6.0.7