Make expanding truncated filenames more general and add support for lookup tables#515
Make expanding truncated filenames more general and add support for lookup tables#515raymond-rebbeck wants to merge 2 commits intointersystems:mainfrom
Conversation
isc-tleavitt
left a comment
There was a problem hiding this comment.
@raymond-rebbeck thank you for yet another helpful PR! I need to think on this one a bit before merging; it will need at least minor changes but might make sense to further generalize for non-class (and LUT) document types while we're at it.
| if (externalNameExtension = "cls") { | ||
| &sql(select %DLIST(Name) into :possibleNames from %Dictionary.ClassDefinition where Name like '%'||:internalName) | ||
| } elseif (externalNameExtension = "lut") { | ||
| &sql(select %DLIST(distinct TableName) into :possibleNames from Ens_Util.LookupTable where TableName like '%'||:internalName) |
There was a problem hiding this comment.
I think some additional work might be needed to generalize this. Two major reasons:
- We want this to work on non-interoperability-enabled namespaces, where Ens_Util.LookupTable isn't available. This is a blocking issue for merge of this PR.
- We want this to work for other document types as well, not just cls and lut. (e.g., I could also see truncation popping up with with .DFI)
There might be an elegant (code-wise) approach using %Library.RoutineMgr:StudioOpenDialog that would hit all relevant cases at once, but I'd be concerned about the possible performance impact. Another approach could be using the List query of the relevant %Studio.AbstractDocument subclass directly based on the extension.
There was a problem hiding this comment.
Thank you for the excellent feedback. Based on this I am thinking that attempting to address this by improving the truncated name expanding logic may not be the ideal approach and I have instead put together #517 to hopefully address this more robustly, at least for pulls initially.
|
Closing this in favor of #517 |
Makes expanding truncated file names from git pull a bit more general and adds support for handling lookup tables. The same concept is applied to lookup tables as was previously introduced for classes in #511
After resetting my local branch back to the first ever commit I can use this to do a pull and successfully import a codebase containing 600+ lookups with names as long as 56 characters.