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. > >> - 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. 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. -James
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
