2) Ensure the config file refreshes successfully (of course).
3) Verify in PR that the values of the feature are available in the probe-values list.
4) Verify in PR that the feature is enabled in the Probe Configuration.
5) Verify in your PR Database that a table does not exist describing the data generated by this feature. The goal of this issue is to invert the truth of this last test. :-)
* Ideally *
The feature name, which appears in PR as "javascript::Local Foursquare Venues Feature", would be submitted to PR Importer with a "PROBE" value of e.g. "LocalFoursquareVenuesFeature", i.e., something that can be created as a table name in Postgres. But, as long as it's a valid Postgres table-name string distinct from all other currently-possible table names, any string is fine.
Repro:
1) Create a ML feature in JS in the config file, e.g. our FourSquare feature:
{ "features": [ { "name": "Local Foursquare Venues Feature", "feature": "PurpleRobot.loadLibrary('foursquare.js'); PurpleRobot.log('LOADED FS LIB'); metadataForLocation(probe['LATITUDE'],probe['LONGITUDE']);", "formatter": "'No. of nearby venues: ' + result['venue_count'];", "sources": [ "edu.northwestern.cbits.purple_robot_manager.probes.builtin.LocationProbe" ] } ] }
2) Ensure the config file refreshes successfully (of course).
3) Verify in PR that the values of the feature are available in the probe-values list.
4) Verify in PR that the feature is enabled in the Probe Configuration.
5) Verify in your PR Database that a table does not exist describing the data generated by this feature. The goal of this issue is to invert the truth of this last test. :-)
* Ideally *
The feature name, which appears in PR as "javascript::Local Foursquare Venues Feature", would be submitted to PR Importer with a "PROBE" value of e.g. "LocalFoursquareVenuesFeature", i.e., something that can be created as a table name in Postgres. But, as long as it's a valid Postgres table-name string distinct from all other currently-possible table names, any string is fine.