Re: [anjuta-devel] RFC: Symbol-db future

[Naba Kumar <naba kumar gmail com>]

Hi Jhs,

On 12/10/10, Johannes Schmid <jhs jsschmid de> wrote:
> As it would take too long to rescan those files everytime and we already
> have the global database I was thinking about creating a temporary
> (in-memory) database holding only the symbols we want. Pseudo SQL
>
> SELECT WHERE (file-list contains filename) from symbols >> temporary
> database
It can easily be just a query on the main DB with additional condition
to filter by list of files. If indexing is done for that field and
entries are all associated with their respective files (which I am
quite positive they are from my last look). A temporary table
shouldn't be necessary. Temporary tables have other issues such as
keeping them up to date.

The only issue I see here is that the list of files could be quite
large when taken into account recursive nature of includes. And, as a
result, can have some significant impact on queries. This is total
speculation, though. It could very well be insignificant too. We could
also limit the files to only one level of include. Which will limit
the files, and also encourage users to include files for the APIs he
uses instead of depending on multi-level includes (which is generally
considered bad practice).

There is a similar bug open by Massio to filter by project
(https://bugzilla.gnome.org/show_bug.cgi?id=625657). They fall in
similar category to extend SdbQuery class to include those new
filters. I have had a look at code and got some idea how it could be
done.

> As a sidenote, that temporary database could be used for the "File" tab
> or symbol-db, too.

I find the file tab more useful for searching symbols in the file
being edited. Searching inside the included files is less useful in
that context.

Thanks.

Regards,
-Naba