creating a content system

Manuel Amador rudd-o at amautacorp.com
Wed Aug 10 23:11:07 CEST 2005


> I don't think you ever want to be doing indexing on nfs shares. Ever. 
> Actually nothing outside user home directories should be indexed. Then 
> a system like the one Scott proposed for tenor where you search outside 
> using links could be utilized.

oh,no... at least it should index /usr/share/doc and /usr/share/man!!!

what's wrong with indexing all locally mounted file systems?  Tons of
people keep documents on their /mnt/windows_c... why should we require
for each one of them to manually configure these folders to be indexed?

> > Aaron, now that you are near to Trolltech, could you please ask them
> > to speed up the development of QtSQL? Even the version which is
> > shipped with Qt4 sucks. I would really e glad to use that library
> > because then we could use whatever DBMS we want to use (PostgreSQL
> > and MySQL only to name a few).

You should choose a database as soon as possible, instead of trying to
make your application work will all databases.  After all:

1. if your daemon is per-user you'll need a database cluster for that
user in a hidden $HOME/.indexer directory, and a database daemon running
for that user.  That is completely platform-dependent code (platform in
the sense of chosen database)

2. queries you will be writing will sadly perform or work differently
across databases, so there's not much of a point in abstracting database
adaption, when your final choice should already be set on stone, based
on inherent database brand properties, like query speed and whether the
database you want does actually support what you want.  I initially
started SS with ZODB and ZCatalog, only to find out that I had to
rewrite the catalog code because it did not perform very well (huge
memory costs), and then went for postgreSQL only to find out that its
text indexing was really, really poor, then chose MySQL and stuck with
that.  I would have been better served if I had run actual tests on each
database and started choosing the right database ASAP.  The upside is
that I wrote good code to init and start a per-directory database
cluster and daemon, a module to automatically catalog Python objects'
properties, and another module to build and auto-optimize interesting
MySQL queries.  Reusable code, haha =).


> 
> It's about 100 miles per hour. Depends whether there's wind or not. 
> Phases of the moon also affect the speed of development. 
> AKA don't ever expect a reasonable answer to a stupid question. If you 
> have something that is an actually a question (where "it sucks, i can't 
> use it" is _not_ a question) then I could try to answer it.
> 
> Zack
> 
-- 
Manuel Amador                   <rudd-o at amautacorp.com>
http://www.amautacorp.com/            +593 (4) 220-7010


More information about the Klink mailing list