Last Comment Bug 411591 - expose frecency as a sort order for place queries
: expose frecency as a sort order for place queries
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: Bookmarks & History (show other bugs)
: Trunk
: All All
: P2 normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 437243 394038 630225
Blocks: 455651 437245 437246
  Show dependency treegraph
 
Reported: 2008-01-09 15:42 PST by (not reading, please use seth@sspitzer.org instead)
Modified: 2011-05-02 14:58 PDT (History)
15 users (show)
dietrich: blocking‑firefox3.5-
dietrich: wanted‑firefox3.6+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description (not reading, please use seth@sspitzer.org instead) 2008-01-09 15:42:18 PST
expose frecency as a sort order for place queries.

something along the lines nsINavHistoryQueryOptions.SORT_BY_FRECENCY_DESCENDING / ASCENDING.  

this could be useful for extension authors or for people wanting to do interesting things with place: queries.

note:  

in our search term builder (at some point) we want to have ui for all (or most) of our query options, but having "Frecency" in the UI is going to be tough to localize.

spun off from bug #411293
Comment 1 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2008-01-09 15:57:19 PST
some bad software call it "relevance", IIRC.
Comment 2 Ed Lee :Mardak 2008-02-21 12:55:47 PST
We'll need this if we want a smartbookmark type thing that shows the top 10 most frecent pages.

The query would be something like..

SELECT url, title FROM moz_places ORDER BY frecency DESC LIMIT 10

But I see some existing super-optimized stuff for nsNavHistory::ConstructQueryString

And we would either need to return another column for frecency or just keep it internal and sort on it for the general non-optimized/frecency ASC query... ?
Comment 3 Marco Bonardo [::mak] 2008-02-21 16:08:45 PST
(In reply to comment #2)
> SELECT url, title FROM moz_places ORDER BY frecency DESC LIMIT 10

if you come to see those into the Library probably you will need more then those 2 columns. an optimized query should limit before selecting, nothing fancy here
Comment 4 Ed Lee :Mardak 2008-02-21 16:12:22 PST
So do something like..

SELECT <desired columns>
FROM moz_places
WHERE id IN (
  SELECT id
  FROM moz_places
  ...
  LIMIT 10)
Comment 5 Marco Bonardo [::mak] 2008-02-21 16:26:48 PST
yes, similar to the actual most visited query or history menu query
<desired columns> should be the same as other queries (based on index definition in the file)
Comment 6 Ed Lee :Mardak 2008-02-28 10:18:24 PST
Ondrej: Would you be able to add a new sort order for frecency seeing that you're familiar with the results code from working on bug 385245?

Sorting would just use the frecency column in moz_places. Potentially we might want a "super-optimized" version as well.
Comment 7 Ondrej Brablc 2008-02-29 05:43:56 PST
This should be the same case as visit_count, so very easy to implement. No super-optimized version is needed.
Comment 8 Marco Bonardo [::mak] 2008-02-29 05:51:07 PST
(In reply to comment #7)
> No super-optimized version is needed. 

it depends if we need to join with moz_historyvisits, in that case we should always limit in the inner select, this depends where we want to expose this frecency, if we create a smart frecency bookmark and the user will open that into the library we will need also history columns

Comment 9 Henrik Skupin (:whimboo) 2008-08-03 15:35:46 PDT
Any news here? It would be great to have it fixed for Firefox 3.1. 
Comment 10 Alex Faaborg [:faaborg] (Firefox UX) 2008-08-13 21:01:04 PDT
We probably don't want to actually call this "frecency" if we add the collumn, given that it will be hard to localize things that aren't actually words.  Perhaps popularity?
Comment 11 Marco Bonardo [::mak] 2008-08-14 02:29:47 PDT
what about "relevance" as Mano suggested in comment #1
Comment 12 Alex Faaborg [:faaborg] (Firefox UX) 2008-08-14 03:52:28 PDT
yeah, relevance sounds ok
Comment 13 Dietrich Ayala (:dietrich) 2008-10-15 21:30:34 PDT
Approving blocking+ for the 3.1 release. This has been requested by extension authors, sync implementors, and will be needed internally for other 3.1 features.
Comment 14 Dietrich Ayala (:dietrich) 2008-12-01 10:56:03 PST
Bug 455651 was cut from 3.1, so this doesn't need to block the release.
Comment 15 Dietrich Ayala (:dietrich) 2009-01-13 10:48:30 PST
would be great for extension developers and sync services, marking wanted+ and keeping on 3.1 radar.
Comment 16 Gervase Markham [:gerv] 2009-11-26 06:46:59 PST
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Comment 17 Marco Bonardo [::mak] 2011-05-02 14:58:07 PDT
was implemented in bug 630225.

Note You need to log in before you can comment on or make changes to this bug.