| 1 |
On 10/23/2014 01:55 AM, Brian Dolbec wrote: |
| 2 |
> What I wonder, is why the following two classes aren't in the portage |
| 3 |
> namespace. There is far too much logic embedded in the _emerge |
| 4 |
> namespace. Most probably under the portage/dpapi subpkg. Looking at |
| 5 |
> them, they do look very similar to the portdbapi and vardbapi classes. |
| 6 |
> They are just stripped down and optimised for this data. They also |
| 7 |
> don't seem to use any _emerge specific namespace modules that I saw. |
| 8 |
> |
| 9 |
> Perhaps with a file name of index.py or indexers.py |
| 10 |
|
| 11 |
The classes aren't really designed for general use, so that's why I left |
| 12 |
them bundled in _emerge.search. However, the classes could certainly be |
| 13 |
fleshed out for general-purpose use. |
| 14 |
|
| 15 |
In their current state, the indexer classes implement only the minimal |
| 16 |
functionality required by the search class. A drawback of the current |
| 17 |
IndexedPortdb design is that it holds all of the index data in memory at |
| 18 |
once. I took this approach because that allowed it to easily fit the |
| 19 |
dbapi interface used by the search class. |
| 20 |
|
| 21 |
In the future, we might decide to rewrite the search class so that it |
| 22 |
processes the index as a stream, which will allow individual search |
| 23 |
results to be displayed as soon as they are located [1]. This rewrite |
| 24 |
will require a new index API. |
| 25 |
|
| 26 |
So, considering that we probably want a new index API in the future, we |
| 27 |
might save some unnecessary effort and stick with the |
| 28 |
special-purpose/minimalistic IndexedPortdb/Vardb adapters for now. |
| 29 |
|
| 30 |
[1] https://bugs.gentoo.org/show_bug.cgi?id=412471 |
| 31 |
-- |
| 32 |
Thanks, |
| 33 |
Zac |
Archives