use sqlite instead of mork for history back end

RESOLVED FIXED in Future

Status

()

Firefox
Bookmarks & History
--
enhancement
RESOLVED FIXED
14 years ago
10 years ago

People

(Reporter: shaver, Unassigned)

Tracking

unspecified
Future
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 -
blocking-aviary1.5 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

In addition to indexing, one doesn't have to reimplement SQL in open coding
(f.e., groupby), and there are a variety of tools available for poking at
sqlite.  It's also multi-process/thread safe, when used correctly, and doesn't
have to be maintained by us.  I think it's a win, and Ben prodded me to hack up
something appropriate.

Interim patch coming up

- autocomplete works, though doesn't have quite the right semantics WRT 
  explicitly-typed prefixes yet
- history pane works, in all the views I could see
- RDF interface mostly works, except
  - GetSources
  - notifications
  I'm going to do the latter with triggers, and the former is just a matter of 
  spending the time.

You'll need to have sqlite-devel installed, and be building on Unix or else make
appropriate arrangements in build/Makefile.in.

The code got a bit simpler, too:
 3 files changed, 893 insertions(+), 2586 deletions(-)
Created attachment 150158 [details] [diff] [review]
trunk diff for firefox

I guess I should move this to the aviary branch, too...
Created attachment 150168 [details] [diff] [review]
aviary patch for firefox

This catches up to the aviary branch, uses a precompiled query for checking if
a URL is already in the history, fixes some very silly TRIGGER bugs, and
abandons the fragile-and-not-clever-enough update-or-insert logic in
AddPageToDatabase.

With either of these patches, by the by, you will want to blow away your
history file first.  I'll put some migration in later, as well as a facility
for schema alteration.

Updated

14 years ago
Hardware: PC → All

Comment 3

14 years ago
I don't suppose it's possible to get this into 1.0?  If not, any idea of the
priority the devs put on this?  

I ask because it currently takes over 30 sec (!) to open the Go menu with the
size of my history file and I have a really don't want to have to wipe out my
history.
Flags: blocking-aviary1.0?
It's certainly not 1.0 material, especially since this patch needs to be
reworked to use sqlite3 for i18n-friendliness, and then the RDF notification
pieces need to be wired up more effectively.

In terms of developer priority, there is one very active Firefox developer who
is basically full-time on issues related to this and other efficient, shared
store issues for the post-1.0 roadmap.  So your pain, with which I do indeed
sympathize, should have an end in sight.
Assignee: shaver → vladimir
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Target Milestone: --- → After Firefox 1.0

Updated

14 years ago
Blocks: 223476, 266627

Comment 5

14 years ago
(In reply to comment #4)
> It's certainly not 1.0 material, especially since this patch needs to be
> reworked to use sqlite3 for i18n-friendliness, and then the RDF notification
> pieces need to be wired up more effectively.
> 
> In terms of developer priority, there is one very active Firefox developer who
> is basically full-time on issues related to this and other efficient, shared
> store issues for the post-1.0 roadmap.  So your pain, with which I do indeed
> sympathize, should have an end in sight.

Could you point to this roadmap which references these store issues? Thanks.

Comment 6

14 years ago
Is this going to happen for FF 1.1? Things are _so_ painful right now, when you
have a large history file...

Updated

14 years ago
Flags: blocking-aviary1.1?

Updated

14 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1-

Comment 7

14 years ago
(In reply to comment #6)
> Is this going to happen for FF 1.1? Things are _so_ painful right now, when you
> have a large history file...

It was marked to block 1.1 and then unmarked, so I'd say no. :-(

Comment 8

13 years ago
taking

I am going to be busy with moving to chicago, but would like to go ahead with
the migration when I get the chance.
Status: NEW → ASSIGNED

Updated

13 years ago
Assignee: vladimir → mikegoodspeed
Status: ASSIGNED → NEW

Updated

13 years ago
Status: NEW → ASSIGNED

Updated

13 years ago
Assignee: mikegoodspeed → nobody
Status: ASSIGNED → NEW
QA Contact: mozilla → history

Comment 9

13 years ago
My I request that the sqlite we build has a standard name (like libsqlite3.so or
sqlite3.dll) rather than be subsumed in a mozilla storage package.

The reason for this is basically one of sharing code. NSS would like to
eventually use sqlite3 for it's database. I would like to not have to build
sqlite3.dll in NSS itself, however NSS needs to be build standalone (without
mozilla), as it has many non-mozilla customers (mostly servers). As part of this
goal, I'd like to build NSS so it can use the system sqlite if it exists on the
target platform, but still be able to build sqlite for platforms that do not
already supply sqlite.

Thanks,

bob
We could support using a system sqlite, if desired, and if the system sqlite had
all the fixes and such that we need (including future encryption patches, etc.).
 Please file another bug on that, because it has nothing to do with porting
history over.

Comment 11

13 years ago
what is the status of this bug?
what is bloking its inclusion?

current history database makes FF block for some seconds several times, so we should change this as fast as possible and solve several bugs (dups?) all at once.
Blocks: 193236, 222717

Updated

13 years ago
No longer blocks: 266627

Comment 12

13 years ago
How does "places" being out affect (or not) this bug?

Comment 13

13 years ago
How does "places" coming out affect (or not) this bug?

Comment 14

13 years ago
cant this one be closed? Places took over?

Comment 15

13 years ago
Fixed by bug 266174.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Updated

10 years ago
Component: History → Bookmarks & History
QA Contact: history → bookmarks
You need to log in before you can comment on or make changes to this bug.