Feature: alternative sorting for Name matching methods

SysOp wrote:

Would you please create a separate post with your enhancement suggestion and an example describing what you mean by "sorting the filtered results by length first?" Which length?

PS. The 2 new methods have been developed in response to users asking to allow filtering object names ignoring their prefixes. So if all tables in a database begin with a prefix like TBL_and all views begin with VW_ prefix, typing the prefixes wouldn't be required to locate *all* names containing the same common word. For example, TBL_Orders table and VW_OrdersSummary view will appear both in the popup after typing word Order.

Yes, that's practical. But there are other occasions when it comes in handy and the 'obstructing' string is not always a prefix. Take a look at the screenshot:

This is from a traffic control database of a public transportation company in Hungary, the word 'jarat' means 'line'. There are many functions/views/whatever related to lines, therefore most of them contain the word 'jarat'. Using both "Name Contains Key String" and "Name Contains Characters from Key String" to filter the popup contents will result in the picture above. Typing the string 'jarat' will filter out most of the irrelevant objects but there are still too many objects to select from and the desired one (table 'jarat' in this case) is many rows below the one where the cursor is. And there's nothing I could do to make the list narrower, as typing any letter beyond the last one would make table 'jarat' vanish from the list. But if the filtered result set was ordered by object name length in the first place and alphabetically in the second, table 'jarat' would be either the top item or at least very near to the top. If it's not the item we're looking for, it'll be filtered out on the next keypress anyway.

AFAIK, the filter is "read ahead". I mean it looks for the next character in the substring following the last one found. Perhaps an even more sophisticated solution would be to order the result by the position of the last character found and alphabetically after that. This way the rest of the items with identical front part (or front part length) would be ordered alphabetically, rather than sorted by their length.

Thank you. I think I now understand what you mean by "object name length." I think the right wording for that would be "closest match" and I would define it as names that begin with the match string go to the top of the list and appear sorted alphabetically (full name match will appear first of course in this case), then go objects having a full matching suffix(see my example below), then go objects having a partially matching suffix starting with the matching string, then everything else sorted alphabetically

Example: list of object names containing word jarat

If my algorithm is applied, after typing "jarat" we will see

Do you think that would work well in your case?

I'm sorry, I made the mistake of trying to describe the method instead of trying to describe the desired result. Also, the "Name Contains Characters from Key String" method could cause quite a confusion here when it comes to defining terms 'closest' and 'closer' matches. On the other hand, it a very good mind game to practice selecting item in the least keypresses. Before this feature there were many items that required 10 or more. Now some of those (excluding few annoying exceptions like 'jarat') were reduced to 3 or even 2. Which in turn results in overall increase of productivity gain. Then again, achieving the proper order with closest matches and partial matches won't be a simple task at all.

Even though it's less effective than "Name Starts..." in this case, I just love it :)

And to answer your question, I imagine that would work exceptionally well in many cases, yes.

I understand.

That's why I personally think there is no single method that works well for everybody and for all environments; users should be able to pick the best method available for their environment and personal preferences. Hope we can improve on that and add more methods soon, the foundation seems to be already there, we just need more types of string matching and list sorting functions.

Nice. I'm eagerly awaiting what this feature will evolve into. It looks very promising.

Any progress on this matter?

Thank you. This request for this enhancement is in the queue but we will be unable to start working on that before 6.4 release is out (6.4 is expected by end of this week / beginning of next)

	SysOp wrote:
	Thank you. This request for this enhancement is in the queue but we will be unable to start working on that before 6.4 release is out (6.4 is expected by end of this week / beginning of next)

Any word on 6.4? Best guess is a delay due to Oracle pushing 12c out?

We are working on resolving 2 bugs that are holding up the release. hopefully they will be resolved by the end of the week or earlier.

Hi! Any progress on this matter?

None? :(

Yes and no. I see in the system that some enhancements/changes have been completed in regard to this matter (sorting options in snippet macros), but there is no stable build yet that I can provide to you.

Well... At least there's still hope :)

I'm looking forward to this feature too.

We now have a stable preview build of version 6.5 available. If you are interested in trying it, please email to supportATsofttreetech.com and ask for a download link