🔍 MiloDB: Finding Old Teases

[althyna]

Yes, I think I could add that. The total hits is an accumulation of all matched search terms, so the information is there, somewhere. Do you have any ideas on how it could be represented in the UI?

My first instinct is to just add this as a column to the result table. This makes natural sense?

So say my search query is - text contains 'edge'

Then in the result table, one of the columns is basically the count of occurrence of whatever the query searches for. The column name could be, say, count.

Now since its in the table, I can click on that column and sort it by descending/ascending order.

This is super helpful in my opinion and I have been using milodb extensively to find teases with particular keywords - I just have to do it manually now.

For instance, I can find teases that talk about edging the most, or stroking the most, etc. etc.

I was trying to think of how it could be represented when you have a complex query like the following:

Code: Select all

text contains edge and text contains balls and text contains stroking and rating >= 4 and (text matches "(tie|attach|connect|loop|fasten)[^\.\?!;]+(bottle|weight|dumbb?ell|heavy|weighted)" or text matches "heavy (object|item|weight)|(any|some)thing heavy" or text matches "bottle of water|water.?bottle|empty bottle" or text matches "\W(1|2)(l\W| litre)|\W(one|two) litre" or tag contains bottle or tag contains weight) and text matches "(play(ing)? with|tease|flick|squeeze|pinch|pull|twist|rub|massage|around|treat|slap|whack|attention)[^.\?!\n]+nipple" and (text matches "(clover|nipple).?clamps" or text matches "cloth(es?)?[ -]?(peg|pin)" or text matches "clamps[^.?!\n]+nipples") and (title contains humiliation or summary contains humiliation)

This query contains the following search terms without the boolean logic:

Code: Select all

text contains edge
text contains balls
text contains stroking
rating >= 4
text matches "(tie|attach|connect|loop|fasten)[^\.\?!;]+(bottle|weight|dumbb?ell|heavy|weighted)"
text matches "heavy (object|item|weight)|(any|some)thing heavy"
text matches "bottle of water|water.?bottle|empty bottle"
text matches "\W(1|2)(l\W| litre)|\W(one|two) litre"
tag contains bottle
tag contains weight
text matches "(play(ing)? with|tease|flick|squeeze|pinch|pull|twist|rub|massage|around|treat|slap|whack|attention)[^.\?!\n]+nipple"
text matches "(clover|nipple).?clamps"
text matches "cloth(es?)?[ -]?(peg|pin)"
text matches "clamps[^.?!\n]+nipples"
title contains humiliation
summary contains humiliation

While each one of those could be shown as a column heading, it would end up as a very wide table.

The only way I can imagine it working would be to do (something like) extend the existing "Hits" column to show a drop-down list of the search terms so that one could be selected, and it could show the hit-count for each search term in the menu.

I am thinking of it similar to how a count(*) query will show up in a SQL setting. Number of unique matches overall. The way I think of the other scenario, where you give count per item sounds more like a count(*) over group by. This could potentially be an added option setting or group by clause maybe, where the user could potentially also get to group by particular query clauses and see values for them separately. This could definitely be very powerful and open up a lot of use cases, although implementation wise this would obviously be more complex.

And easy way to implement a group by count could be as simple as opening up a group by style prompt box (optional) at the top right below the query box. So you can choose to, say, write your queries like you normally do, then in the group by, tell which entities you want to group by.

So for instance, if your query is:

text contains 'edge' or text contains 'stroke'

group by count query could be:

text contains 'edge', text contains 'stroke'

This could then give you both. For every row that shows up in the query result set, you could run a count for each group by. Would give the user more flexibility. If nothing is shown up here, you just give the total top level result as basically the number of overall result returns. Users could then also group by counts for something that's not a part of the selection.

For instance, for the same query above, I could do a group by count query like:

text contains 'anal', text contains 'post orgasm'

So I basically get the counts of mentions of 'anal' and 'post orgasm' in all teases that contain the terms 'edge' or 'stroke'.

Pretty useful and powerful imo.

[FrozenWolf]

My first instinct is to just add this as a column to the result table. This makes natural sense?

So say my search query is - text contains 'edge'

Then in the result table, one of the columns is basically the count of occurrence of whatever the query searches for. The column name could be, say, count.

Now since its in the table, I can click on that column and sort it by descending/ascending order.

This is super helpful in my opinion and I have been using milodb extensively to find teases with particular keywords - I just have to do it manually now.

For instance, I can find teases that talk about edging the most, or stroking the most, etc. etc.

I was trying to think of how it could be represented when you have a complex query like the following:

Code: Select all

text contains edge and text contains balls and text contains stroking and rating >= 4 and (text matches "(tie|attach|connect|loop|fasten)[^\.\?!;]+(bottle|weight|dumbb?ell|heavy|weighted)" or text matches "heavy (object|item|weight)|(any|some)thing heavy" or text matches "bottle of water|water.?bottle|empty bottle" or text matches "\W(1|2)(l\W| litre)|\W(one|two) litre" or tag contains bottle or tag contains weight) and text matches "(play(ing)? with|tease|flick|squeeze|pinch|pull|twist|rub|massage|around|treat|slap|whack|attention)[^.\?!\n]+nipple" and (text matches "(clover|nipple).?clamps" or text matches "cloth(es?)?[ -]?(peg|pin)" or text matches "clamps[^.?!\n]+nipples") and (title contains humiliation or summary contains humiliation)

This query contains the following search terms without the boolean logic:

Code: Select all

text contains edge
text contains balls
text contains stroking
rating >= 4
text matches "(tie|attach|connect|loop|fasten)[^\.\?!;]+(bottle|weight|dumbb?ell|heavy|weighted)"
text matches "heavy (object|item|weight)|(any|some)thing heavy"
text matches "bottle of water|water.?bottle|empty bottle"
text matches "\W(1|2)(l\W| litre)|\W(one|two) litre"
tag contains bottle
tag contains weight
text matches "(play(ing)? with|tease|flick|squeeze|pinch|pull|twist|rub|massage|around|treat|slap|whack|attention)[^.\?!\n]+nipple"
text matches "(clover|nipple).?clamps"
text matches "cloth(es?)?[ -]?(peg|pin)"
text matches "clamps[^.?!\n]+nipples"
title contains humiliation
summary contains humiliation

While each one of those could be shown as a column heading, it would end up as a very wide table.

The only way I can imagine it working would be to do (something like) extend the existing "Hits" column to show a drop-down list of the search terms so that one could be selected, and it could show the hit-count for each search term in the menu.

I am thinking of it similar to how a count(*) query will show up in a SQL setting. Number of unique matches overall. The way I think of the other scenario, where you give count per item sounds more like a count(*) over group by. This could potentially be an added option setting or group by clause maybe, where the user could potentially also get to group by particular query clauses and see values for them separately. This could definitely be very powerful and open up a lot of use cases, although implementation wise this would obviously be more complex.

And easy way to implement a group by count could be as simple as opening up a group by style prompt box (optional) at the top right below the query box. So you can choose to, say, write your queries like you normally do, then in the group by, tell which entities you want to group by.

So for instance, if your query is:

text contains 'edge' or text contains 'stroke'

group by count query could be:

text contains 'edge', text contains 'stroke'

This could then give you both. For every row that shows up in the query result set, you could run a count for each group by. Would give the user more flexibility. If nothing is shown up here, you just give the total top level result as basically the number of overall result returns. Users could then also group by counts for something that's not a part of the selection.

For instance, for the same query above, I could do a group by count query like:

text contains 'anal', text contains 'post orgasm'

So I basically get the counts of mentions of 'anal' and 'post orgasm' in all teases that contain the terms 'edge' or 'stroke'.

Pretty useful and powerful imo.

I see what you mean now, thanks for the clarification. That's quite a lot of work, so I'll do it in stages. I'll probably refer to the search terms in the query as 'query-search-terms', and the additional search terms as 'highlight-search-terms'. Therefore, after a query has been run on the query-search-terms, then a search within the filtered teases would be done with the highlight-search-terms, which don't filter the teases, just count the occurrences.

It seems like the individual features of the change would include:

• Display counts for each query-search-term
• Sort teases by selected query-search-term
• Allow entry of highlight-search-terms
• Following the execution of a query, run the highlight-search-terms
• Display counts for highlight-search-terms
• Sort teases by highlight-search-terms
• Extend the user guide

[althyna]

I was trying to think of how it could be represented when you have a complex query like the following:

Code: Select all

text contains edge and text contains balls and text contains stroking and rating >= 4 and (text matches "(tie|attach|connect|loop|fasten)[^\.\?!;]+(bottle|weight|dumbb?ell|heavy|weighted)" or text matches "heavy (object|item|weight)|(any|some)thing heavy" or text matches "bottle of water|water.?bottle|empty bottle" or text matches "\W(1|2)(l\W| litre)|\W(one|two) litre" or tag contains bottle or tag contains weight) and text matches "(play(ing)? with|tease|flick|squeeze|pinch|pull|twist|rub|massage|around|treat|slap|whack|attention)[^.\?!\n]+nipple" and (text matches "(clover|nipple).?clamps" or text matches "cloth(es?)?[ -]?(peg|pin)" or text matches "clamps[^.?!\n]+nipples") and (title contains humiliation or summary contains humiliation)

This query contains the following search terms without the boolean logic:

Code: Select all

text contains edge
text contains balls
text contains stroking
rating >= 4
text matches "(tie|attach|connect|loop|fasten)[^\.\?!;]+(bottle|weight|dumbb?ell|heavy|weighted)"
text matches "heavy (object|item|weight)|(any|some)thing heavy"
text matches "bottle of water|water.?bottle|empty bottle"
text matches "\W(1|2)(l\W| litre)|\W(one|two) litre"
tag contains bottle
tag contains weight
text matches "(play(ing)? with|tease|flick|squeeze|pinch|pull|twist|rub|massage|around|treat|slap|whack|attention)[^.\?!\n]+nipple"
text matches "(clover|nipple).?clamps"
text matches "cloth(es?)?[ -]?(peg|pin)"
text matches "clamps[^.?!\n]+nipples"
title contains humiliation
summary contains humiliation

While each one of those could be shown as a column heading, it would end up as a very wide table.

The only way I can imagine it working would be to do (something like) extend the existing "Hits" column to show a drop-down list of the search terms so that one could be selected, and it could show the hit-count for each search term in the menu.

I am thinking of it similar to how a count(*) query will show up in a SQL setting. Number of unique matches overall. The way I think of the other scenario, where you give count per item sounds more like a count(*) over group by. This could potentially be an added option setting or group by clause maybe, where the user could potentially also get to group by particular query clauses and see values for them separately. This could definitely be very powerful and open up a lot of use cases, although implementation wise this would obviously be more complex.

And easy way to implement a group by count could be as simple as opening up a group by style prompt box (optional) at the top right below the query box. So you can choose to, say, write your queries like you normally do, then in the group by, tell which entities you want to group by.

So for instance, if your query is:

text contains 'edge' or text contains 'stroke'

group by count query could be:

text contains 'edge', text contains 'stroke'

This could then give you both. For every row that shows up in the query result set, you could run a count for each group by. Would give the user more flexibility. If nothing is shown up here, you just give the total top level result as basically the number of overall result returns. Users could then also group by counts for something that's not a part of the selection.

For instance, for the same query above, I could do a group by count query like:

text contains 'anal', text contains 'post orgasm'

So I basically get the counts of mentions of 'anal' and 'post orgasm' in all teases that contain the terms 'edge' or 'stroke'.

Pretty useful and powerful imo.

I see what you mean now, thanks for the clarification. That's quite a lot of work, so I'll do it in stages. I'll probably refer to the search terms in the query as 'query-search-terms', and the additional search terms as 'highlight-search-terms'. Therefore, after a query has been run on the query-search-terms, then a search within the filtered teases would be done with the highlight-search-terms, which don't filter the teases, just count the occurrences.

It seems like the individual features of the change would include:

• Display counts for each query-search-term
• Sort teases by selected query-search-term
• Allow entry of highlight-search-terms
• Following the execution of a query, run the highlight-search-terms
• Display counts for highlight-search-terms
• Sort teases by highlight-search-terms
• Extend the user guide

That sounds great! Will look forward to it whenever you release :)