[kepler-dev] [Bug 5722] Check for problems with sanitized RecordToken labels

bugzilla-daemon at ecoinformatics.org bugzilla-daemon at ecoinformatics.org
Wed Dec 5 12:56:02 PST 2012


http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5722

--- Comment #2 from Derik Barseghian <barseghian at nceas.ucsb.edu> ---
So far I haven't been able to come up with a concrete realistic/common usecase
where this causes problems. I looked at some of the actors we were concerned
about:

The EML 2 Dataset actor actually already converts spaces to underscores for
recordToken labels. See "Sedgwick Reserve Aphid Population Growth Rate
Experiment" where e.g. "baby greens" becomes "baby_greens".

The DataTurbine actor only uses "timestamps" and "data" for record labels,
regardless which of the 2 output type options are chosen, and even on it's
newer "specific channel" ports.

The R actor doesn't seem to produce any RecordTokens like I expected. I checked
3 likely candidates:
an R dataframe comes out as:
_dataframe_:/Users/derik/.kepler/cache-2.4/modules/r/Unnamed1_1354739437414/mydataframe-RExpression-1.sav

an R list comes out as:
_object_:/Users/derik/.kepler/cache-2.4/modules/r/Unnamed1_1354739437414/mylist-RExpression-1.sav

an R matrix doesn't come out (ugh).

The Database Query actor produces RecordTokens, but core, cache, and provenance
DBs don't have columns with spaces in their names, so I wasn't able to easily
cook up an example problem.

I want to keep thinking about this a bit, and discuss w/ others.

If we do keep the r64639 sanitize change, should we consider not making it
possible to create unsanitized record labels altogether to be consistent? Right
now RecordToken(Map fieldMap) constructor does not sanitize, while
RecordToken(String[] labels, Token[] values) does.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20121205/6f04a7af/attachment.html>


More information about the Kepler-dev mailing list