On Thu, 27 Apr 2000, Brandon wrote:
<snip>
> The table doesn't need to go in the datastore. You can put it there, but
> then you have to upgrade your datastore for new key types. Now that I've
> give in to key handlers, I'd put the table in the key handler. The
> datastore can either store everything by CHK (assuming we make CHKs
> fundamental, which I think we should), thereby conveniently
> eliminating/merging duplicate files, or under a unique index (an integer).
There has to be one DataStore used for routing. One can put entries in several
tables for the pure lookup (searchRef and searchData) but they have to go in
the same table for routing (findClosestKey). And in that table they cannot all
be stored by CHK or by a unique index, they have to be stored by their Freenet
Key, whether it is a CHK, KHK, or an SVK - because that is what has to be used
for closeness, or request will not route correctly.
> As far as the advantages of multiple tables, I suppose you could index it
> under a single table. It's important that the datastore doesn't have to
> know what the type means. One table per keytype would make for faster
> searches since items indexed under other keytypes wouldn't be looked
> at. I'm not really sure how you'd go about turning a two part key
> (keytype, key) into a single index key in a sensible way.
For the lookups we use a hashtable - it has O(1), so making more tables will not
make the lookups any faster.
--
Oskar Sandberg
md98-osa at nada.kth.se
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
