161701 - move last-page-visited out of prefs.js

Status: RESOLVED FIXED

(Core :: Preferences: Backend, defect, P3)

Description

[Alec Flett]

After some discussion that fell out of bug 155080, we've decided to clamp down
on preferences that make prefs.js constantly dirty. The biggest offender, by
far, is browser.history.last_page_visited - we set that every time we visit a
page, which is just rediculous.

This bug is to store this value in history.dat instead. My initial idea is to
create a new table in the mork database which essentially stores name/value
pairs that have metainformation about the entire database - and one such value
will be "last_page_visited"

cc'ing bienvenu for mork advice in case there's another way of doing this - I
remember long ago mccusker talking about making a meta-properties API for mork
databases, but I'm not sure what became of that.. Also, since we'll be
constantly  writing out new journal data to disk as a result of this, I want to
make sure to do the absolute minimum change so that each journal change is small.

cc'ing bnesse because this will allow him to make prefs save on a timer, without
constantly writing prefs.js out to disk.

Comment 1

[David :Bienvenu]

you can add meta row information to an existing table, or you can add a new
table. IIRC, history has one table, right, with a row for every history entry?

To get the meta row for a table,
		table->GetMetaRow(db->GetEnv(), nsnull, nsnull, &m_metaRow);

You can then get and set columns on that row to your heart's content.

Comment 2

[Alec Flett]

yes! that's exactly what I'm looking for. Thanks.

Comment 3

[Wesha]

Guys, isn't the "last page visited" == "the page in history with the most recent
date"? Why separate item for it?

Comment 4

[Wesha]

Guys, isn't the "last page visited" == "the page in history with the most recent
date"? Why separate item for it?

Comment 5

[David :Bienvenu]

just guessing, but it's much faster to keep track of the last page than it is to
grovel through all the pages looking for the one with the latest last visited date.

Comment 6

[Wesha]

Just save it as a very first record when saving history file...

Comment 7

[Wesha]

Besides, it's a matter of good style. One of the DB rules saying, 
"Thu shalt not be able to retireve the same data record in more than a single
unique way, as desynchronization havoc might be caused otherwise". =^.^=

Comment 8

[Alec Flett]

because there is no fast way to retrieve that entry - I'd have to go through
every entry in the file looking for the latest date.

Comment 9

[Alec Flett]

ok smart guy, lets see a patch then. :)

Comment 10

[Wesha]

Sorry I can't, blocked by the bug 159723. :-b

Comment 11

[David :Bienvenu]

Just think of it as an index of 1 - databases have indexes that allow you to
retrieve data quickly, right? :-)

Comment 12

[Alec Flett]

Attachment: use mork's meta-row

This turned out to be very easy. Here's a simple implementation using mork's
GetMetaRow()

can I get r=bnesse, sr=bienvenu?

Comment 13

[Wesha]

Toldja! =^.^=

Comment 14

[Alec Flett]

no, you told me to fix it in another way, and said THAT would be easy :)

Comment 15

[David :Bienvenu]

I think for consistency, you should clean up mMetaRow in nsGlobalHistory::CloseDB()

Comment 16

[Alec Flett]

Attachment: use mork's meta-row v1.01

oops yeah - I discovered that without that, I crash on exit :)

Comment 17

[David :Bienvenu]

Comment on attachment 95414 [details] [diff] [review]
use mork's meta-row v1.01

consistency, not crashing, it's all good :-) sr=bienvenu

Comment 18

[Brian Nesse (gone)]

Comment on attachment 95414 [details] [diff] [review]
use mork's meta-row v1.01

r=bnesse.

Comment 19

[Alec Flett]

cool thanks. fixed.