Closed Bug 645860 Opened 10 years ago Closed 10 years ago
Studies should have a way to write metadata
This came up in a discussion about the garbage collection study; the study would like to be able to record metadata about the user's hardware. This is essentially study-specific metadata. Up until now we've done stuff like this by writing the value into one of the columns of the schema as a special 'status' event, but that's a really ugly kluge (it violates the schema and makes it hard to filter on when querying the database). There's currently no way for a study to write to metadata because the metadata object doesn't exist until submission time. We can implement this either by creating temp metadata storage earlier in the process (a database table or something) and providing an API to write to it; or else (and this is easier) having the task object query the study to say "any more metadata for me?" when collecting all the other metadata right before submission. So a study can optionally implement a provideMetadata() method.
Severity: normal → critical
Priority: -- → P1
Target Milestone: --- → 1.2
Implemented in http://hg.mozilla.org/labs/testpilot/rev/7dd6788c1500 I tried to write it in as error-tolerant a way as possible (it will do the right thing if a study's getStudyMetadata() method throws an exception or if it returns something that's not an array) but we're not currently sanitizing name or value strings; should think about whether doing so is needed for security reasons.
Also how to handle the case where it returns an invalid object or where name or value is not a string.
Comment on attachment 524919 [details] [diff] [review] Patch to mozilla-central to add this feature Should TestPilotExperiment_getStudyMetadata use a try/catch in case the task method throws an exception?
Yes it should. Here's a patch with exception handling.
Attachment #525207 - Flags: review?(mark.finkle) → review+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: Mozilla Labs → Mozilla Labs Graveyard
You need to log in before you can comment on or make changes to this bug.