IWHD API Suggestions

Martyn Taylor mtaylor at redhat.com
Fri Sep 9 17:12:32 UTC 2011


Hi Jim,

We don't already do this, but actually Matt suggested the exact same 
thing in a conversation we had.

The only issue I can see here, is keeping the local cache up to date.  I 
can't say how fresh the data needs to be right now.  But we have 
separate services, some that read and others that write to iwhd.  This 
would probably mean refreshing the data reasonably regular.

It's certainly not how we do it at the moment, so it could considerable 
increase our current efficiency, especially when working closer to the 
bottom of the tree.

Thanks alot

Martyn
On 09/09/2011 05:56 PM, Jim Meyering wrote:
> Matt Wagner wrote:
>> On Fri, Sep 09, 2011 at 04:39:59PM +0200, Jim Meyering wrote:
>>> [ Whether this change would be a mere optimization and hence whether
>>>    it's justified aside (are there actual use cases with timings and/or
>>>    round-trip counts?) ]
>> I don't have timing data, but I can say this -- I wrote code to fulfill
>> my particular use case: given an array of image UUIDs, show which
>> provider images exist for each.
>>
>> To do so, I have to make individual calls for the attributes of every
>> single build, target image, and provider image that exists in iwhd to
>> see if they're part of a chain I care about.
> Hi Matt,
>
> Maybe you already do this?
>
> At least with the current architecture, I would suggest that you read as
> much as you need initially to construct the graph of relationships.  While
> doing that, you can add back-links, as needed, so that when you iterate
> through UUIDs, each query merely examines your in-memory representation
> and you get results in O(1) time per UUID.
>
> Then, if the read-all phase is still found to be too slow, say, due to the
> number of queries required, we can think about adding an API to provide
> larger batches of information, rather than imposing application-specific
> structure on iwhd.



More information about the iwhd-devel mailing list