Jason Tackaberry wrote: > What we _can_ do is delay processing the row data into a more > manageable form (i.e. unpickling the pickle column and moving the > row data into a dict that's easier to work with) until after a > simple file list is displayed in the UI. I think most of the big > wins will be these kinds of tricks, because working with python's > data structures is slow.
I already have that in mind. The resulting File object will examine the results when needed. > I think Martijn has very grandiose ideas for what mediadb should be. I > think he wants the user to be able to add his own attributes to files, > with the ability to construct arbitrarily complex queries on these > attributes. So he is advocating the single table, one-row-per-attribute > approach which makes this easy to implement. But it is slow. And > anyway, DBOverlord already lets the user add custom attributes and > construct queries on these attributes. The main difference, though, is > that a decision has to be made about what kind of attribute it will be. > Martijn's approach means all attributes are searchable. Mine means that > they're only searchable if you want them to be. This is the key > compromise in my approach. But this is a solvable problem in the UI. We we also add a generic key/value table, we should make sure we select this data for a File only when needed. Dischi -- According to my calculations the problem doesn't exist.
pgpF5bSBV3Bge.pgp
Description: PGP signature
