Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re^8: Running SuperSearch off a fast full-text index.

by dmitri (Priest)
on Jun 10, 2007 at 20:13 UTC ( #620354=note: print w/replies, xml ) Need Help??

in reply to Re^7: Running SuperSearch off a fast full-text index.
in thread Running SuperSearch off a fast full-text index.

I've successfully checked out from the svn repository via https. I'll wait for you to set up trunk like a module distro. If you haven't got a name you prefer for the base module namespace over "MonkSearch", that would be my suggestion.
    MonkSearch works for me. Should it be App::MonkSearch maybe? Also, we may end up with more than just the indexers -- there will also be the web interface(s).
I just had a glance at the code in your CPAN distros, and your stuff look great.
    Except SQL::Tidy! Thanks ;)
My impulse is to conduct our discussions here on PerlMonks... what do you think?
    In this thread?
  • Comment on Re^8: Running SuperSearch off a fast full-text index.

Replies are listed 'Best First'.
Re^9: Running SuperSearch off a fast full-text index.
by creamygoodness (Curate) on Jun 10, 2007 at 20:34 UTC

    Sure, that'll work... Randy Kobes' CPAN search modules are under CPAN::Search::Lite, FWIW.

    In this thread?

    Probably not all in this thread. We might start a new thread called "MonkSearch - spider" to deal with spidering issues, for example.

    I think it's important to facilitate participation by anyone in the PerlMonks community who wants to join in. The downside is that we might end up creating more messages than the PerlMonks threading model is optimized for, but this isn't that big a project and I think the volume will be manageable.

    Marvin Humphrey
    Rectangular Research ―
      It is a good point you make about other monks' participation. We can link to threads we create from this thread's parent node. The only thing that baffles me is which category would the threads related to the development of MonkSearch belong to? Seems like an off-topic wherever we place them.
Re^9: Running SuperSearch off a fast full-text index.
by dpavlin (Friar) on Jun 10, 2007 at 20:38 UTC
    I would also prefer discussion and than summary on wiki.

    OOH, storing nodes locally in SQLite seems like an overkill. With good filesystem there is no reason to complicate crawler with DBI code, just dump files on disk.

      The reason I think that SQLite would be useful is that if we want to separate the spider from indexer, finding the articles to update in the index is as simple as
      instead of searching the filesystem. Stored on the filesystem, we will need code to
      • search,
      • store, and
      • update
      the documents. SQLite provides all of that for free. Want to move to a different machine? -- The database is a single file. Plus, who knows what other useful things SQLite's flexibility will allow us to do?
        I've worked on spiders that have used the file system, and spiders that have used databases. It's certainly cheaper to use the file system. But thinking about the size of the dataset, we can easily afford to put these records into a database. There are only c. 600,000 records, and they're small -- not even full web pages. I like the idea of using SQLite.
        Marvin Humphrey
        Rectangular Research ―

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://620354]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (6)
As of 2021-10-21 12:29 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (83 votes). Check out past polls.