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. > - 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? Jeremy _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
