Matching multiple fragments of an object name

buckleybuckley Posts: 69
edited February 17, 2015 9:51AM in SQL Prompt
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?

Comments

  • Aaron LAaron L Posts: 596 New member
    Hi Tom,

    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:
    UCiduIR.png

    Uem7:
    UTbdlJq.png

    If you're on the latest and you're still not seeing the matches I wonder if you've found a bug.

    Thanks,
    Aaron.
  • Hi 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
  • buckleybuckley Posts: 69
    edited February 11, 2015 8:29AM
    Hi Aaron,

    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
  • Hi Aaron,

    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
  • Hi Aaron,

    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
  • Aaron LAaron L Posts: 596 New member
    Ah - I just had a look at your video and I think I might know what's going wrong.

    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?
  • Hi Aaron

    Thanks, it's all clear now finaly :) Thanks for sticking with me

    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
  • Aaron LAaron L Posts: 596 New member
    Hi 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:
    int usp_EviMon07;
    int usp_EVIMON07;
    
    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.
  • Hi 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.
  • Aaron LAaron L Posts: 596 New member
    Ah ok, that makes sense - Thanks for explaining it! :)

    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.
Sign In or Register to comment.