----- "James Laska" jlaska@redhat.com wrote:
One challenge I see is designing a schema that can efficiently accommodate current and future front-end reporting needs. I often worry if we try to build something too universal, will it become useless? If the cost (time+energy) of making something generic is too high, I'd certainly be in favor of multiple front-ends and results servers. Do we have a good handle on what the specific schema needs each front-end might have?
Well this is certainly one of the harder parts. Unfortunately I don't really know much about databases and I have just basic knowledge about database design practices. But I believe this should not be rushed, because a lot of code would have to be re-implemented after such change. So I think it will take some week(s) of discussion.
If we know all the test types (installer tests, repository tests, rpm package tests, etc), we should be able to create a schema generic enough to accommodate all of those. If some new test type appears later, then it may be quite difficult to put it into an existing schema (unless the schema is really very generic, but then it's harder to work with).
It is also possible to have several databases and some daemon listening to all incoming results and classify them into relevant databases according to the result type.
Do we have any database expert amongst us? Anyone? :)
PS: On IRC James mentioned we can have a look at autotest DB schema, so I attach a link: http://autotest.kernel.org/wiki/TkoDatabase
autoqa-devel@lists.fedorahosted.org