On Tue, 2007-04-10 at 11:43 -0400, James Bowes wrote: > Jeremy Katz wrote: > > On Mon, 2007-04-09 at 18:41 -0400, James Bowes wrote: > >> So here, for your amusement and subject to your general mockery, are two > >> patches that modify the database in such a way as to break compatibility > >> with existing code. > > [snip] > >> Some things that could be done but probably shouldn't: > >> - Convert the values from ints to strings as they are pulled out of the > >> database. I'd rather not do this for performance reasons, but it would > >> mean that the API is not broken (see epoch related code in the yum patch) > > > > The advantage, though, is that the API is not broken. I think this is > > pretty compelling, even if it's at the cost of some performance. As > > more and more people build tools on top of the API, we have to be more > > and more aware of this. Because if we're constantly changing the API, > > then the value of the yum API drops substantially. > > > > It might be interesting to see what the performance difference is if we > > just leave epoch as a string rather than an int and do the rest of the > > changes. I have a hunch that it wouldn't be that different. And API > > consistency is then far less painful. > > I can run some numbers, unless someone else wants to do it. I feel that > representing numbers as numbers is the more correct thing, but we can > always do that later.
Yeah, but if we have to use it as a string in the code, then it's probably going to be faster to just keep it as a string in the db. > >> - Store the pkgId as raw data rather than a printable string. This would > >> save 20 bytes per pkgId, but pysqlite makes it very difficult to do > >> anything with this value once you've gotten it out of the db. > > > > How so? > > You store the value as text, and pysqlite will complain because it's not > unicode. So you store it as a blob, and pysqlite will return it as a > buffer, which can't be used as a hash key, so you have to convert it to > a string before you can use it. The code is then icky. I'd be happy to > dig up what I have done so far with it, so that others can make it > better. Come to think of it, if we're not breaking the API, then every > time you take a pkgId out of the database, or put one in (say, for a > query), you're going to need to do some magic to go from 20 to 40 bytes. Ewww :) > And if we're gonna change the db, we mayaswell get as many changes in at > once. > > Now, if the api isn't broken, who's up for putting this in pre 3.2? Then > we can just forget about generating dbv9 and dbv10 at the same time, and > leave that problem for later. If we're careful not to break API, then I'd be okay with going with it for pre 3.2 as long as we got it in very soon and got a package into rawhide for a little testing prior to F7 test4. Jeremy _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
