Re: [Lxr-dev] Status of this project?

[Paul S. <ps...@ne...>]

On Wed, 2007-03-21 at 07:21 +0100, Gregor Hartmann wrote:

> >Personally, I'd like to see the entire LXR::Files class reimplemented.
> >IMO, the right way to do that is to have a class that represents a
> >single file

> Sounds like a great idea to me. Some time ago I noticed that files are 
> copied even when they are in the filesystem already (not in cvs). This 
> could be cleanly ommited then also by accessing the file directly.
> Spechial care has to be taken then that the file is not modified and 
> most important not deleted at the end.

After looking further I also think there's also a lot of opportunity to
fix the Index class and subclasses: right now LXR::Index is essentially
empty, but the reality is that, because of Perl's DBI interface which is
common across databases, with only a few minor exceptions all the
database access for all different databases will be identical.  I think
all the content of the LXR::Index::* subclasses should be pushed up into
the LXR::Index class, and the subclasses left there only for
implementing any DB-specific extensions that are required.  This would
make it much simpler to support new databases and would ensure that any
enhancements made to one DB were available to all without any extra
work.

-----
Actually the patch I sent before relied on another change I made, that
wasn't included.  I'm including a new one that doesn't require any
changes to the LXR::Files class to support it.

I have a number of other cleanups and enhancements I can send.  I'm
including here a fix to the "not all .h files are indexed" issue I
mentioned the other day; after a night's sleep I was able to pretty
easily figure out where that cross-referencing was done.  My fix looks
up filenames in the database if they are not found via the current path
lookup methods.  If only one file is found that matches, a link to it is
added.  If more than one file is found that matches, a link to a search
for that filename is used as the href.  I only include the MySQL version
here but the Postgres one is the same.  I'm not sure about Oracle... we
might have to let someone who has a copy fix it up.

Both of these patches will have some fuzz because of other enhancements
I've made, but they should apply.