Closed Bug 660572 Opened 9 years ago Closed 9 years ago

Separate Bookmarks, History, Etc into Distinct SQLite Databases

Categories

(Toolkit :: Places, enhancement)

x86
Windows XP
enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: david, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20110511 SeaMonkey/2.1
Build Identifier: 

If my history is deleted, corrupted, or otherwise requires restoration from a backup, I will then lose any new bookmarks I saved since my last backup.  Similarly, if my bookmarks require restoration, I will then lose any changes in my history.  While all these items are somewhat related, they should not be all held in the same database.  

Reproducible: Always
I think there would be performance impacts to breaking these apart because of the way there are used in the awesomebar.
Whiteboard: [wontfix?]
(In reply to comment #1)
> I think there would be performance impacts to breaking these apart because of
> the way there are used in the awesomebar.
indeed, although mak may have some ideas on how to work around that...
The penalty of a performance impact is might not be as important to a user as the inability to restore history without losing recent additions to his or her bookmarks or (vice versa) the inability to restore bookmarks without losing recent history.
Whiteboard: [wontfix?]
It may be feasible, but due to recent researches I don't think it's worth it. Bookmarks is merely a hierarchy of some of the pages in history, splitting databases we should still retain all urls in a single database, most likely the history one for the locationbar, then you would be left with a database containing meaningless numbers.

I don't think this is an interesting use-case, losing recent bookmarks may be annoying but it's hardly an unrecoverable situation (how many bookmarks you may have added after the last backup that you completely forgot about?).
Also, restoring bookmarks doesn't remove any history so I don't understand your second point.
See bug #660543 and bug #660646 for some background.  

Re comment #4, last paragraph:  If I restore my bookmarks from a backup of places.sqlite, I will lose any history since the backup was generated.  

History and bookmarks are not necessarily in a one-for-one relationship, and they should not be.  History can expire -- at least eventually -- but not bookmarks.  On the other hand, a URI can be in history without being bookmarked.  In some cases, I have the same URI bookmarked twice.  However, I would expect that, if I visit a URI twice, only the last visit will appear in my history.
(In reply to comment #5)
> Re comment #4, last paragraph:  If I restore my bookmarks from a backup of
> places.sqlite, I will lose any history since the backup was generated.  

Indeed you should not, we give you json backups for that scope.

I don't understand the scope of the rest of comment 5, I understand pretty well how the system works. I was absolutely in favor of splitting the databases in the past, but after lots of work on the system, today I think would be a really bad choice, as explained in comment 4, bookmarks is just a table containing some number, splitting it won't help any of your requests.
Re comment #6, last paragraph:  Does that mean that, if a bookmark is not visited in a long time -- long enough for its history entry to be deleted -- the bookmark will also be deleted?
(In reply to comment #7)
> Re comment #6, last paragraph:  Does that mean that, if a bookmark is not
> visited in a long time -- long enough for its history entry to be deleted --
> the bookmark will also be deleted?
No.
However, manually deleting a history entry from two months ago would also delete the entry from yesterday for the same Web page.  

I am a retired software test engineer.  I had a career spanning more than 30 years working with very large, complex software systems for operating military space satellites.  In my professional opinion, the current design for browser history is broken.
Please, stop mixing bugs, you have filed 3 separate bugs, they have practically nothing in common since each of them could be handled and fixed apart from the other ones, but in each of them you are talking about the others, this is going to be confusing to anyone. If you want to provide useful feedback you should stick to a topic and bring it on.
(In reply to comment #9)
> However, manually deleting a history entry from two months ago would also
> delete the entry from yesterday for the same Web page.
Stop trying to tie all your bugs together.  I'm not sure how you think it will benefit, but it's certainly a violation of bugzilla etiquette (1.1), and it's annoying the developers likely to fix your bugs.  Please stop.

> I am a retired software test engineer.  I had a career spanning more than 30
> years working with very large, complex software systems for operating military
> space satellites.  In my professional opinion, the current design for browser
> history is broken.
Arguments from authority aren't really useful here.
I would like to point out that places.sqlite in my profile is 10.0 MB.  The only thing larger in my entire SeaMonkey installation is xul.dll at 14.2 MB.  The difference is that xul.dll is a static file that does not change while places.sqlite is a dynamic file that is constantly being rewritten.  

If places.sqlite were broken apart per this RFE, smaller chunks would be rewritten at a time, taking less I/O time.  Furthermore, each rewrite of a very large file increases the likelihood that the file itself will become fragmented on the user's hard drive, requiring even more I/O time.  On top of all that, holding a large places.sqlite in memory makes less memory available for Web pages and other aspects of browsing, thus increasing the need to swap memory (even more I/O).
(In reply to comment #12)
> If places.sqlite were broken apart per this RFE, smaller chunks would be
> rewritten at a time, taking less I/O time.  Furthermore, each rewrite of a very
> large file increases the likelihood that the file itself will become fragmented
> on the user's hard drive, requiring even more I/O time.  On top of all that,
> holding a large places.sqlite in memory makes less memory available for Web
> pages and other aspects of browsing, thus increasing the need to swap memory
> (even more I/O).
I don't think you understand how SQLite works.  None of this is true in regards to places.sqlite.
I understand that places.sqlite is a single file on my hard drive.  I also understand that it increases in size as history entries are added.  

Whether SQLite processes the file incrementally as a database -- entry by entry -- or all at once, the overall file will eventually become fragmented on my hard drive.  When SQLite then searches the file for an entry (incremental processing) or processes it (reading or writing) all at once, fragmentation of the file on my hard drive will increase the I/O time required.
(In reply to comment #14)
> Whether SQLite processes the file incrementally as a database -- entry by entry
> -- or all at once, the overall file will eventually become fragmented on my
> hard drive.  When SQLite then searches the file for an entry (incremental
> processing) or processes it (reading or writing) all at once, fragmentation of
> the file on my hard drive will increase the I/O time required.
places.sqlite grows in 10MB chunks to compensate for this fragmentation problem.  We also VACUUM the database once a month to relay it out on disk in a contiguous manner.  Therefore, none of the problems you have cited are valid concerns at this point.
I give up!  However, I have submitted bug #662858 to allow users to tailor block sizes and vacuum frequencies for places.sqlite.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.