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

[Massimo Cora' <maxcvs email it>]

Hi,

On 12/16/2010 12:09 PM, Johannes Schmid wrote:
> Hi!
>
> > we may create temporary packages that grow up with the included files.
> > The files belonging to temporary packages may also be part of 'normal'
> > packages, so that no hard-dependence is made.
> > This would require some changes on db logic but it's feasible without
> > too much work. The packages will then represent meta group of files. We
> > can save the temporary ones on project session, and load them at
> > project-load time. They can be saves as hashes so that they'll be unique.
> > What do you say?
>
> I am not sure how the semantic you talk about will look like, maybe you
> can explain that a bit.
>
> Saving in the project-session might not make much sense because the
> temporary database would always exist for one file only (the file
> currently open that we have the headers scanned). This database would be
> really temporary in a sense that it might only exist as long as a file
> is open.

I think we're talking about two different things.

* You'd like to keep global db but preferring in-memory dbs (aka 
temporary dbs), one for each file. Those in-memory dbs will be populated 
with headers retrieved by "gcc -MM file.c -I..." or similar commands.
Those in-memory would be also be populated getting a subset of symbols 
taken by the on-disk global db and the queries performed only on 
in-memory dbs just created.


* My point of view is to not create in-memory dbs for system headers, as 
it would be unnecessary. It could be already done using simple temporary 
packages (whom name could be identified by hashes) directly into the 
on-disk global db.
In this way we could have: 1. all system packages scanned once and put 
in the on-disk global db. 2. subsets of files from those packages to 
create temporary packages.

package gtk+  [gtk_header1, gtk_header2, ...]
package glib  [glib_header1, glib_header2, ...]
package temp1 [gtk_header1, glib_header2, ...]
package temp2 [foo_header1, no_system_package_header2, ...]

This can avoid the maintenance and creation problems of in-memory dbs, 
and could allow quick queries with simple joins: all the symbols are in 
the same db and the performances will be good, avoiding the 
proliferation of N in-memory dbs.
The ids of temp1, temp2 packages can be saved into session-properties to 
retrieve the already scanned headers when a project is reloaded, or we 
can delete the temporary packages when we close the global db.
The deletion can be done only on the package name, leaving the scanned 
files on global-db.
You should think of temp-packages as a group of files ids. They will not 
have hard-link to the files as the other system packages e.g.: the 
scanned files will not be removed once the temp-packages are deleted.

I see an usage of in-memory dbs when the headers are not system headers 
but instead when the user opens .c or .h that aren't part of the current 
opened project. The 'File' tab will be populated with that data.


thanks and regards,
Massimo