Github user cestella commented on the issue:
https://github.com/apache/metron/pull/622
So, in my mind the feature here is the enablement of batch analytics on the
profiles. To that end, I'm in general in favor of a decodable row key. I think
that the question really isn't a ToC *or* a decodable rowkey. I think, rather,
we will want both. The two will follow different access patterns. A decodable
rowkey sans ToC will be suitable only for full table scan-style access. A ToC
would enable to slice or dice by profile/entity/etc.
That being said, a ToC without a decodable rowkey is substantially less
nice. Without being able to decode the rowkey, we will not be able to
regenerate the ToC to provide alternative indexing. I see this as a first step
to enable a broader discussion on just what kind of access semantics beyond
Get/Put we want to place on the profiles.
All that to say, I'm in favor of the effort. I worry at the impact going
forward to existing profiles, though. From the point where we do this, we will
create a fork whereby new profiles and old profiles diverge. I think we need
to discuss the migration story more explicitly and see if it is plausible to
create a migration tool that is fuzzy (i.e. will look at the existing profiles
and try to pick them apart).
I'd be ok for that work to be a follow-on, but I would want the plan to be
very explicit and I would be -1 for a release until it's in.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
