Barbie sent me some Metabase questions, but I'm copying my reply to the cpan-testers-discuss list in case it's of interest or use to others in the future.
On Tue, Jan 5, 2010 at 4:19 AM, Barbie <[email protected]> wrote: > Just wanted to go through a few questions regarding the Metabase, > hopefully you can clarify any misunderstandings I currently have. Happy to help. Metabase is really a family of distributions. it's broken up so that the ones that need to run on clients (E.g. Metabase-Fact) can have minimal dependencies, whereas the ones designed to run on the server can be Modern Perl, with Moose and other nice, author-time-saving modules. > Firstly your Metabase repo doesn't appear to be up to date (at least it > didn't appear so last night). There seems to be several references to > modules that aren't there. Have these been created locally and not > uploaded or are they waiting to be written? examples are > 'Metabase::Fact', 'Metabase::User::Profile', 'Metabase::User::Secret' > and 'Metabase::Report'. Here are all the repos you may need to know about (git://github.com/dagolden/XXXXXX.git) for the following XXXXXX: Client side: * metabase-fact -- the "fact" (and user) base classes * cpan-testers-report -- Metabase::Fact classes for test reports * metabase-client-simple -- submits facts to metabase-web (NO search) * test-reporter-transport-metabase -- adaptor between Test::Reporter and Metabase Server side: * metabase-fact -- the "fact" (and user) base classes * cpan-testers-report -- Metabase::Fact classes for test reports * metabase -- the "storage" components * metabase-web -- the catalyst server to provide REST around a metabase > Secondly the 'fact' table consists of 4 fields, 'guid', 'type', 'meta' > and 'content. Am I right in understanding that 'content' is the raw data > as passed via the HTTP request, and 'meta' is a JSON representation of > that? If so, I thought that we were going to submit the reports as JSON, > so what difference is there between 'content' and 'meta'? The 'content' is usually a data structure. For example, a CPAN::Testers::Report is a Metabase::Report. The 'content' of a Metabase::Report is an array of Metabase::Fact subclasses. In the case of CPAN::Testers::Report, one of those will be a CPAN::Testers::Fact::LegacyReport, the 'content' of which is hash like this: content => { grade => $tr->grade, osname => $tr->osname, osversion => $tr->osversion archname => $tr->archname perlversion => $tr->perl_version_number textreport => $tr->report }, The 'textreport' field is the one with the actual test report email. So actually getting that means something like this (note, I'm writing from memory and this is untested): # $ctr is a CPAN::Testers::Report my $legacy = grep { $_->isa('CPAN::Testers::Fact::LegacyReport') } $ctr->facts; my $email = $legacy->content->{textreport}; The 'meta' field is generally private -- it stores two types of metadata. "Core metadata" are things that are common to all Metabase::Facts (like GUID, creator, etc.). "Content metadata" is derived from the content. If we had "image" facts, an example of content metadata could be the size, height or width. In the case of CPAN::Testers::Report, the content meta fields are currently just the same as the content metadata from the LegacyReport class: grade, osname, osversion, archname and perlversion. (There is support for an "nntpid' field, but I don't think we'll wind up using it after all). To really "get" Metabase, you need to spend some time grokking Metabase::Fact and Metabase::Report. > In regard to CPAN Testers Reports, what values of 'type' are expected? 'type' is a conversion of Perl class names to dashed equivalents that are more web friendly. E.g. CPAN::Testers::Report would be CPAN-Testers-Report. > Does a report consist of many facts, or is the report the entire fact? A Report isa Fact and its content is an array of things that are Facts. > When we discussed this last year in Brum, I got the impression that the > intention was to split the report into components (e.g the test output, > comments, prereq versions, config, etc), each being a separate fact. If > this is still the case, how does the report reference the child facts? LegacyReport and TestSummary are the only required facts currently, and TestSummary is really just the metadata from LegacyReport. Eventually, LegacyReport will go away and we'll only have structured data, but that requires brand new clients. Right now, Test::Reporter::Transport::Metabase doesn't parse out things like prereqs from the report because I don't want to make CPAN::Testers::(report parser of some sort) a prerequisite. I'd rather just eventually write the new client that provides everything in structured form. > What does the Index provide that each fact doesn't? As I read it > currently, it just seems to add more metadata to each fact. An Archive just associates a GUID to serialized (possibly compressed) fact content. The Index associates metadata with a GUID. Content metadata doesn't need to be transmitted and might be wrong (e.g. if a client has an older version of a Fact subclass than the server does). The Index regenerates the content metadata using whatever version of the Fact subclass is current on the server. > Lastly (at the moment ;)), what do you plan for the user profile to > contain? Right now, it has a name and one or more email addresses and a "secret" (i.e. password). The secret is going to be split out. So a "profile" is just a GUID associated with a full name and email addresses. There will probably be a JSON file on each tester's machine containing that information and I want to pre-generate a profile for each testers we have listed in the addresses file and send them to testers so they can use the same profile as was used to convert (and associate) their legacy reports. > Before going any further I just wanted to make sure I was going in the > right direction :) Seems likely. I'd spend some timing looking at Test::Reporter::Transport::Metabase to see how it generates the CPAN::Testers::Report, then look at that, Metabase::Report and Metabase::Fact and the various CPAN::Testers::Fact::* classes. Working with all these libraries simultaneously is a pain, so also see this article: http://www.dagolden.com/index.php/77/codependent-testing-with-mylib/ I hope that helps! David
