Matching multiple fragments of an object name
buckley
Posts: 69 New member
Hi,
Most of the time Prompt reads my mind and comes with the sql object I had in mind when
- typing a single fragment of the name
- typing multiple fragments of the name
For example, the sproc
usp_EviMon07
Is matched when typing
EXEC usp_
EXEC Evi
EXEC Mon07
But also
EXEC uevi
In the last case Prompt will match the first 'u' and the fifth 'e'
This is also visible because Prompt gives the letter a different color where it matched on.
Considering that Prompt matches on multiple fragments I don't get why Prompt does not match
EXEC m7 -- no match
EXEC uem7 -- no match (*)
Or the single fragment '07' for that matter
EXEC 07 -- no match
I'm sure there is a logic behind it but sometimes I fail to see a consistency.
Thank you, Tom
(*) The idea of typing it like this is quite powerful and comes from Resharper (a C# tool).
In Resharper you can type the first letter/number of each "Camel" and it will zoom with a few keystrokes in on the object you were after. (4 keystrokes to match a name with a length of 20 to 30 is common).
If Prompt supports unlimited fragments this camelcase matching would be implicitly supported. Maybe there is a limit to the number of fragments or numbers stop further matching?
Most of the time Prompt reads my mind and comes with the sql object I had in mind when
- typing a single fragment of the name
- typing multiple fragments of the name
For example, the sproc
usp_EviMon07
Is matched when typing
EXEC usp_
EXEC Evi
EXEC Mon07
But also
EXEC uevi
In the last case Prompt will match the first 'u' and the fifth 'e'
This is also visible because Prompt gives the letter a different color where it matched on.
Considering that Prompt matches on multiple fragments I don't get why Prompt does not match
EXEC m7 -- no match
EXEC uem7 -- no match (*)
Or the single fragment '07' for that matter
EXEC 07 -- no match
I'm sure there is a logic behind it but sometimes I fail to see a consistency.
Thank you, Tom
(*) The idea of typing it like this is quite powerful and comes from Resharper (a C# tool).
In Resharper you can type the first letter/number of each "Camel" and it will zoom with a few keystrokes in on the object you were after. (4 keystrokes to match a name with a length of 20 to 30 is common).
If Prompt supports unlimited fragments this camelcase matching would be implicitly supported. Maybe there is a limit to the number of fragments or numbers stop further matching?
Comments
Could I ask which version of Prompt you're currently running? I just gave it a go and the latest (6.4.1.164) should support the behavior you've described:
M7:
Uem7:
If you're on the latest and you're still not seeing the matches I wonder if you've found a bug.
Thanks,
Aaron.
I'm using a recent build, 6.4.1.145
I'll do the upgrade soon as I read a new version will be released next week or so.
Kind Regards, Tom
I did the test with your latest beta
When looking for "m7" the object is not suggested
Also, the intellisense box disappears once I stort typing a number. Maybe an edge case?
Thats weird again right?
Kind Regards, Tom
Here are the screenshots now shared publicly
https://www.dropbox.com/s/cuqs2a40ghp17xn/0007.jpg?dl=0
https://www.dropbox.com/s/5k7oy8ye8ua9d6l/0008.jpg?dl=0
This can be related to my other posts, that I'm somehow carrying over settings from an older version.
Mind you, we are working on citrix where updates to programs are "magically" replicated
The latest build 6.5.0.183 (the one that fixed the cross database intelliprompt) still has the same issues I reported earlier.
To recap:
-- target: usp_EviMon07
-- Is matched
-- EXEC usp_
-- EXEC Evi
-- EXEC Mon07
-- EXEC uevi
-- no match
-- EXEC m7
-- EXEC uem7
-- EXEC 07 -- I think the current behavior of Prompt is to disable intelliprompt when a digit is the first character the user types
In the video you've got "usp_EVIMON07" (the second part all uppercase) this won't match in the same way as "usp_EviMon07" (with CamelCase) we're actually looking for the captial letters when we do the filtering to determine where the individual words are. So uem7 matches against the first u, the first E (after the underscore) but then as it's all uppercase there's no match against the M as we interpret "EVIMON" as one word.
For numbers we don't popup intellisense automatically as it really annoyed some people when they were actually trying to type numbers. You can trigger it manually with ctrl+space or start the identifier with a [ to show you want an object name and not a number.
Hopefully that clears it up?
Thanks, it's all clear now finaly
So Propmt does CammalCase matching much like Resharper does. Is it possible to show below the CamelCasematches the other possible matches? That's the way Resharper reads my mind when doing C#
Kind Regards, Tom
Hmm I'm not sure I fully understand the request, if we include things that aren't matched against then we'll be including quite a bit of noise in the suggestions?
I had a look at the filtering in ReSharper and I think we're already a bit more lenient than them with our matching. Eg. With your example of "usp_EVIMON07" they don't match against "mon07", but maybe you've got some extra settings enabled that I'm missing?
I just created two ints: and then immediately below started typing the example filters from earlier in this forum post to see which matches I get against both uppercase and camel case.
Thanks,
Aaron.
I tested it myself with Resharper 9. Resharper does indeed match just at the starting boundaries of the "tokenized" object name. Than the behavior is that there is it keeps matching if the typed string occurs contiguously. So you are right, it does not match the cases at the start of this post.
"if we include things that aren't matched against then we'll be including quite a bit of noise in the suggestions?"
I think the order is important as the user sees at the first few entries in the intellisense list. If the object isn't there he will look further and scroll in the list.
If the list is started with the current matches (to simplify, partial or CamelCase) and followed by the less likely the user can still pick them.
For example,
The trivial tokenization of usp_EviMon07 is u s p _ e v i m o n 0 7
Lets say the user remembers that work had to be done at the 7th query of project "Evi". Then she can type Evi7 and there is a match within the trivial tokens.
Also the order that the user remembers something is not always right.
For example,
usp_EviMon07 stants for the 7th monitoring sproc for the Evi Project.
If the user types 7mon she will of course not get a match.
She will get a match magically If the Permutations are matched of :
The camelcase tokenization of usp_EviMon07 is usp Evi Mon 07
The permutations are (order is important)
uspEviMon07
uspEvi07Mon
uspMonEvi07
uspMon07Evi
usp07EviMon
usp07MonEvi
Eviusp07Mon
..
07MonEviusp
07MonuspEvi
For 4 tokens that makes 24 in total so the search space gets bigger considerably. (There are data structures that can make this fast though).
Is it worth it? I don't know. The trivial tokenization can have its benefit since the user remembrance of fragments is not necessary that where the Camelcase tokens are. The search space is also not so much bigger. I haven't implemented intellisense so am sure there are lot of details that I don't know of.
I'm _more than happy_ with the improvements that we made and further refinements are maybe to beneficial.
I think it'll be something we'll have to actually play around with to gauge its usefulness - I can imagine some people might get annoyed at some of the more obscure matches it produces. Maybe this would fit in as an experimental feature so we can try it out over a long period.
Thanks!
Aaron.