Smart Groups Title field contains is just not working


#1

Using GarageSale Version 7.0.13 (827), macOS Version 10.12.6 (16G1212)

The Smart Group filter for “Title” is just not working correctly with the “contains” filter.

Are you using some “grep” library that is treating certain “unquoted” characters as special, like “*” and “+” and others (!@#&=>")???

Photo 1 Smart Group returns 11723 items, it should return 0.
Photo 2 Smart Group returns 14187 items, it should return 54.
Photo 3 Smart Group returns 188 items, it should return 5. The “-J” returns ALL Titles that contain a “J”.

Smart Groups Title field contains is just not working 1
Smart Groups Title field contains is just not working 2
Smart Groups Title field contains is just not working 3


#2

I just wrote a lengthy post on why the search terms you are showing in your screenshot wouldn’t possibly work, only to discover that creating a smart group for title contains “+Quantity: 1” works.

So, the behaviour you describe was most likely cause by the smart group editor now re-evaluating items when hitting OK.

Are you still having this issue with GarageSale 7.0.14 Beta 1?


#3

So… Can you explain why this Smart Group (Title Contains “Quantity: 1”) is returning too many listings. It SHOULD ONLY return listings that contain the literal string “Quantity: 1”. It appears that the Smart Group is returning all listings that contain the literal string “Quantity” AND the literal string “1”. GarageSale 6.9.8 returns the correct 6 templates.


Also… I have another Smart Group (Title Contains “-JK”) that is returning 2 items that contain “JK”, not “-JK”. If I change the “contains” to “ends with” is DOES work CORRECTLY, and only shows listings that end with “-JK”. It SHOULD ONLY return listings that contain the literal string “-JK”. It appears that the Smart Group is returning all listings that contain the literal string “JK”.


#4

GarageSale 6 used brute force to evaluate the “contains” smart group rule for text field, whereas GarageSale 7 uses a full text index for these rules.

This means GS 7 maintains a dictionary, which consists of a list of listings that contain a given word. So in your example, Garagesale would lookup all which listings contains the word “Quantity”, wich listings contain the word “1”, and show the listings that are contain both.

The full text index is capable of only returning listing that contain the exact search string, hence the somewhat esoteric option in the search field’s popup, but we haven’t added a way to expose these options in the smart group rule editor yet.

We’ll look if its feasible to use double quoted strings as hint for returning exact matches only.


#5

Hi Ilja,

Ahhh. I see. Now I understand. It is not a “literal” exact string match search. It is a “word” AND “word” AND “word” search, just like the Toolbar Search field.

The behavior of the Toolbar Search field “Show exact matches only” is what I was expecting in the Smart Groups.

This would be a GREAT acceptable solution. Or a new “exact match” popup menu item in the Smart Group Rule Editor… :slight_smile:

Thanx!
Neal


#6

For some reason, I don’t get the behaviour you are seeing when setting up the “-JK” or “+Quanity: 1” smart group rules.

Can you do me a favor and send me a screenshot of the contents of your GarageSale library directory? You can get there through “Help” > “Open Library Folder”. Thanks.


#7

Please disregard my previous post about the library folder screenshot. Can you instead give this version a try and check if the “contains” rules for smart groups is correctly evaluated if you wrap the search string in double-quotes?

http://downloads.iwascoding.com/downloads/GarageSale_7_2018-03-12_1.dmg


#8

YES!

So, for each example text, I open the Smart Group Filter window and click OK. Which should do an immediate “re-calc” and display the current results. Correct?

Are the Smart Group (contains xxx) and (contains “xxx”) case-sensitive??

Title Contains ‘-J’ returns every Title that has a letter ‘J’ in it.
Title Contains ‘"-J"’ now returns every Title that has the string ‘-J’ in it. Correct!

Title Contains ‘-JK’ returns every Title that has the string ‘JK’ in it.
Title Contains ‘"-JK"’ now returns every Title that has the string ‘-JK’ in it. Correct!

Title Contains ‘“Quantity:”’ now works correctly
Title Contains ‘"+Quantity:"’ now works correctly

Doing a “Quantity: 1” Search with “Show exact matches only” DOES return the correct results:

Doing a “+Quantity: 1” Search with “Show exact matches only” DOES return the correct results:

‘space-character’ in Smart Group Contains string gives strange results!

Title Contains ‘Quantity: 1’ returns every Title that has the word ‘Quantity’ AND the letter ‘1’ AT THE END OF ANY WORD.
But
Title Contains ‘“Quantity: 1”’ returns nothing, 0 items!

NOW, Title Contains ‘Quantity: 1’ returns every Title that has the word ‘Quantity’ AND the letter ‘1’ ANYWHERE IN THE TITLE.
AND NOW, Title Contains ‘“Quantity: 1”’ DOES return the CORRECT 5 items!!!

BUT
Title Contains ‘"+Quantity: 1"’ still returns nothing, 0 items!
AND NOW, if I just open the Smart Group Filter window and click OK, Title Contains ‘"+Quantity: 1"’ DOES return the CORRECT 4 items!!!

VERY STRANGE!!!

Another example of STRANGE with spaces:
create Smart Group with title contains ‘space-character’‘space-character’. 0 items.
create a new listing.
add a space to change the new title from “New Listing” to “New Listing” (add a 2nd ‘space-character’ between 2 words).
listing DOES immediately show up in Smart Group. Good. All Correct.
double-click Smart Group to open filter editor. click OK to close.
!!! Smart Group now shows 0 items!!!

And a simple Smart Group filter rule “Title contains ‘space-character’” or ‘Title contains “‘space-character’”’ both return false and 0 items.

It seems like “periodic Smart Group updating” and “immediate Smart Group updating by clicking the rule dialog OK button” are doing slightly different evaluations…

Can you add some Smart Group logging???


#9

That’ probably it.

When you change the smart group rules, we are using our own engine to lookup matches from the database, but when you change a listing, we are using the system libraries to evaluate the listing, since it’s already loaded into memory.

Let me see how we can handle this best.


#10

AH! Yep! Exactly! 2 different evaluation engines! That explains the different results. Makes for very confusing results!! 1 evaluation engine with consistent results would be better… :slight_smile:


#11

Here is another simple example of the different behavior between the 2 different evaluation engines. Smart Group for “Title contains ‘space’‘space’”. Again, 1 consistent evaluation engine would be better… Again, I THINK the macOS runtime comparison method, when changing a listing, seems to be correct.


#12

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.