On Thu, May 24, Duncan Mac-Vicar Prett wrote:
Yes, you have to pass the record id.
The problem lays in another part. When I first thought about the ResolvableConsumer interface, I only expected to have void consumeSomething() methods that accept a struct, but not method that returns ids, because this means the producer (parser) has to keep some status. If you need to keep status, then it would not be feasible to implement consumers like a logger.
Parsers will hapily keep the ids, because otherwise they had to keep the complete data untill they are complete. A (dummy/test)consumer like a logger can probabely use a counter that's used as Id.
However, YaST metadata needs to fill complete package structs, and then add descriptons latter, so it needs to get the id of a consumePackage call.
In case YUM evaluates a 2nd file (besides primary), it will require the same.
Perhaps we should move the complete interface of CacheStore to the ResolvableConsumer call.
The way you designed it, ResolvableConsumer is the interface for the parser. What's not in ResolvableConsumer can't be used by the parsers. CacheStore is one implementation of a ResolvableConsumer. The application/workflow decides, which ResolvableConsumer to used, by creating a CacheStore or DummLogStore or whatever kind of ResolvableConsumer we provide. After creating the concrete object, it's just a ResolvableConsumer and used like a ResolvableConsumer can be used. In case CacheStore extends the public interface, it is kind a of 'back door', hidden from the parser.
What do you think?
Define a consistent basic way to feed data into the database (full data structs). Offer shortcuts for parsers that will benfit from beig able to feed data in pieces (provide Id).
So in your case, the consumePackage would return the id, and then you can fill the filelists using this id, then you only need a map of nvra to id, which is pretty cheap.
PLEASE if you touche the interface,fix this as well: void consumePackageAtom ( const data::RecordId &catalog_id, const data::PackageAtom_Ptr & ) = 0; void consumeMessage ( const data::RecordId &catalog_id, data::Message_Ptr ) = 0; ... All methods doing the same, just with different kinds of data pointer should use the same signature (for the 2nd arg). If you extend an existing interface, try to adapt it's style. Pass either by "value" or by "const &". -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org