Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

search.json and/vs search.sqlite

9 views
Skip to first unread message

Bugra Uytun

unread,
Dec 31, 2009, 9:59:40 AM12/31/09
to
What are the purpose of search.json and search.sqlite files?

There are actually no documentation about search.json and search.sqlite
files in kb.mozillazine.org and also the documentation about "profile
folder" [1] lacks information about search.json.

The only two information that I could found were a bug report "replace
search.json with startup cache" [2] and "Firefox's search engines
management is bad design" [3]. Therefore I assume that search.json is a
cache, and as long as it exists firefox ignores anything in
search.sqlite and and "$PROFILE/searchplugins" folder. Since any new
search-plugin xml file that is copied to searchplugins folder is
ignored. Is this behavior expected or just a bug?

cheers,
bugra.


[1] http://kb.mozillazine.org/Profile_folder_-_Firefox
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=529173
[3] http://forums.mozillazine.org/viewtopic.php?f=7&t=1605835&start=0

Jay Garcia

unread,
Dec 31, 2009, 10:14:33 AM12/31/09
to
On 31.12.2009 08:59, Bugra Uytun wrote:

--- Original Message ---

Google is your friend: http://en.wikipedia.org/wiki/JSON

search.sqlite is simply a database of your installed search engines.


--
Jay Garcia - Netscape/Flock Champion
www.ufaq.org
Netscape - Flock - Firefox - Thunderbird - Seamonkey Support

Bugra Uytun

unread,
Dec 31, 2009, 10:29:39 AM12/31/09
to
On 31.12.2009 16:14, Jay Garcia wrote:
> On 31.12.2009 08:59, Bugra Uytun wrote:
>
> --- Original Message ---
>
>> What are the purpose of search.json and search.sqlite files?
>>
>> There are actually no documentation about search.json and search.sqlite
>> files in kb.mozillazine.org and also the documentation about "profile
>> folder" [1] lacks information about search.json.
>>
>> The only two information that I could found were a bug report "replace
>> search.json with startup cache" [2] and "Firefox's search engines
>> management is bad design" [3]. Therefore I assume that search.json is a
>> cache, and as long as it exists firefox ignores anything in
>> search.sqlite and and "$PROFILE/searchplugins" folder. Since any new
>> search-plugin xml file that is copied to searchplugins folder is
>> ignored. Is this behavior expected or just a bug?
>>
>> cheers,
>> bugra.
>>
>>
>> [1] http://kb.mozillazine.org/Profile_folder_-_Firefox
>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=529173
>> [3] http://forums.mozillazine.org/viewtopic.php?f=7&t=1605835&start=0
>
> Google is your friend: http://en.wikipedia.org/wiki/JSON

thanks, i'm aware of the json format.
please let me repeat my previous question:

'Therefore I assume that search.json is a cache, and as long as it

exists firefox ignores anything in search.sqlite and and
"$PROFILE/searchplugins" folder. Since any new search-plugin xml file
that is copied to searchplugins folder is ignored. Is this behavior

expected or just a bug?'

>
> search.sqlite is simply a database of your installed search engines.

I don't think this really true, since I can remove an entry from this db
but my search box still shows the search-plugin.
Therefore I really don't see the purpose of this db beside for the
additional information 'updateexpir' [4] that most probably is the date
when the plugin should be updated again, but what does the value
'updatedatatype' mean and which values are valid?


cheers,
bugra.


[4]
https://developer.mozilla.org/en/Creating_OpenSearch_plugins_for_Firefox#Supporting_automatic_updates_for_OpenSearch_plugins

G. R. Woodring

unread,
Dec 31, 2009, 1:03:40 PM12/31/09
to

It might be helpful to explain exactly what you are trying to do.

As Jay stated, search.sqlite is a database of installed search plug-ins.
Firefox uses .json files to back up .sqlite database files.

If you are editing or deleting the .sqlite file then it's data would be
different than the back-up and would be considered "corrupt". It would then be
restored from the info in the .json file. The files are intended for the
internal use of Firefox and are not intended to be modified by users. That
Firefox defeats your actions is not only _not_ a bug, it is intended behavior.

The usual method to install a search plug-in is to load it from a site
configured to install the plug-in.

If you are trying to manually add a search plugin by putting it in the
searchplugins folder you will have to delete both the search.sqlite file and the
search.json file. (Do all this with Firefox not running.) When Firefox
restarts it will have no option to back up and will recreate search.sqlite by
reading the contents of the searchplugins folder.

The OpenSearch plug-in format discussed in the link [4] in your other post can
also be installed in IE7 (or IE8). Useful if you need a custom search available
crossbrowser.


--
G. R. Woodring

Gavin Sharp

unread,
Jan 6, 2010, 9:27:54 PM1/6/10
to Bugra Uytun, dev-apps...@lists.mozilla.org
On Thu, Dec 31, 2009 at 9:59 AM, Bugra Uytun <bu...@uytun.com> wrote:
> What are the purpose of search.json and search.sqlite files?

search.json is a JSON cache of all search engines, stored in the
profile. It contains a combination of the information in the plugin
description .xml files and the metadata stored in search.sqlite. It
was added to speed up engine loading (loading stuff from a single JSON
file is quicker than having to read in both search.sqlite and multiple
XML files). The bug you pointed out is suggesting that instead use a
new generic startup cache mechanism that's being developed.

search.sqlite only contains search engine metadata, not the engine
descriptions themselves. Stuff like the engine's position in the
dropdown, it's last update time, the "datatype" to be used for updates
(i.e. Sherlock or OpenSearch), etc.

> is bad design" [3]. Therefore I assume that search.json is a cache, and as
> long as it exists firefox ignores anything in search.sqlite and and
> "$PROFILE/searchplugins" folder. Since any new search-plugin xml file that
> is copied to searchplugins folder is ignored. Is this behavior expected or
> just a bug?

That isn't the expected behavior. We have code in place to detect
changes to the .xml files on disk and invalidate the cache. However
there is a known issue with that code - it uses the lastModifiedTime
of the containing folders to attempt to detect changes, and on Windows
modifications to a file within the folder do not affect that folder's
lastModifiedTime. This shouldn't be an issue on Mac or Linux, as far
as I know. Fixing this bug hasn't been a priority, because it's quite
uncommon for the search engine files on disk to be changed manually,
and people doing that can easily work around the problem by manually
deleting the search.json cache.

Gavin

Bugra Uytun

unread,
Jan 7, 2010, 6:32:11 PM1/7/10
to
thank you, now it makes sense for me.

cheers,
bugra.

0 new messages