1 |
Yes SQL tables are better for that as it's simpler to update them :) |
2 |
|
3 |
2006/3/15, Brian Harring <ferringb@×××××.com>: |
4 |
> On Tue, Mar 14, 2006 at 04:33:06PM +0200, tvali wrote: |
5 |
> > I did think about it now and it seems to me that probably it would be |
6 |
> > much faster if esearch is not just another package, but part of |
7 |
> > portage. |
8 |
> > |
9 |
> > I mean -- functions of portage, which query db, should use esearch |
10 |
> > index wherever they need information, which exists in that index. |
11 |
> > |
12 |
> > As much as i can understand, /var/cache/edb/ contains esearch database |
13 |
> > in many files and esearchdb.py is search index as python script. |
14 |
> |
15 |
> No... |
16 |
> esearch is a static db- only useful for 'frozen' trees, eg rsync |
17 |
> distributed trees with no eclasses in overlays. All cvs users (devs) |
18 |
> run unfrozen trees (readonly/readwrite is better terminology), thus |
19 |
> portage updates the cache db on the fly as needed. |
20 |
> |
21 |
> If esearch was integrated into portage the result would be stale |
22 |
> metadata for cvs users, and stale metadata for rsync users when |
23 |
> overlays with eclasses are involved- no go. |
24 |
> |
25 |
> That and esearch last I looked just generates a giant dict (thus the |
26 |
> cache is in memory), which kind of blows the <25mb mem usage 2.1 |
27 |
> now sports :) |
28 |
> |
29 |
> ~harring |
30 |
> |
31 |
> |
32 |
> |
33 |
|
34 |
|
35 |
-- |
36 |
tvali |
37 |
(e-mail: "qtvali@×××××.com"; msn: "qtvali@×××××.com"; |
38 |
icq: "317-492-912") |
39 |
|
40 |
Ühe eesti internetifirma lehel kohtasin tsitaati: |
41 |
If you don't do it excellently, dont do it at all. Because if it's not |
42 |
excellent, it won't be profitable or fun, and if you're not in |
43 |
business for fun or profit, what the hell are you doing here? |
44 |
Robert Townsend |
45 |
|
46 |
-- |
47 |
gentoo-portage-dev@g.o mailing list |