Skip to content
This repository has been archived by the owner on Feb 21, 2024. It is now read-only.

Proposal: Remove row and column labels #752

Closed
jaffee opened this issue Jul 26, 2017 · 10 comments · Fixed by #1180
Closed

Proposal: Remove row and column labels #752

jaffee opened this issue Jul 26, 2017 · 10 comments · Fixed by #1180
Assignees

Comments

@jaffee
Copy link
Member

jaffee commented Jul 26, 2017

Description

Anecdotally, arbitrary labelling of rows and columns seems to be more confusing than useful.
I'm talking about when you create an index and frame, and you can optionally specify a column label an row label respectively to be used in queries in place of "rowID" and "columnID". Normally to retrieve a row or column, you'd use Bitmap(rowID=<id>, frame=<frame>) or Bitmap(columnID=<id>, frame=<frame>), but if you specified row and column labels, you use those in place of "rowID" and "columnID".

The only value this provides is making queries read in a more relatable way to the data in Pilosa. On the flipside, it increases code complexity (both client and server side), makes it difficult to understand whether a query is accessing a row or column at a glance, and increases cognitive load in that you have to remember which label was used for each frame and index. It also may fragment the language which different groups use to discuss Pilosa and inhibit understanding between different users.

Therefore, in order to simplify Pilosa, and reduce our API surface area, I propose that we deprecate and eliminate the ability to specify arbitrary labels on rows and columns.

The purpose of this ticket is to gather community feedback to determine the level of disruption which this change would cause, and whether we don't understand any important uses of row and column labels.

Success criteria (What criteria will consider this ticket closeable?)

Row and column labels have been removed from Pilosa, the documentation, and any examples or tools which were using them.

@alanbernstein
Copy link
Contributor

Should we codify a deprecation policy? This would be a good place to start.

@travisturner
Copy link
Member

I propose we change it to row and col

@jaffee
Copy link
Member Author

jaffee commented Aug 30, 2017

I'm going to move ahead with this unless there are any objections (including the row/col change). As far as deprecation goes, I think since we're pre-1.0 we just make it clear in the changelog and release notes that this is a breaking change.

@jaffee jaffee self-assigned this Aug 30, 2017
@yuce
Copy link
Contributor

yuce commented Aug 30, 2017

If this is not a priority, why don't we just set the label defaults to row/col (or something else) and remove the bit about specifying labels from the docs ?

@jaffee
Copy link
Member Author

jaffee commented Aug 30, 2017

I think that would lead to confusion, as anyone looking at the code would see references to labels all over the place and it wouldn't be clear what they were for. I'd rather do the work to strip them everywhere now and avoid carrying historical cruft around

@yuce
Copy link
Contributor

yuce commented Aug 30, 2017

There's quite a bit of work to remove the labels feature, apart from pilosa internals: docs, getting started, clients, client docs, (and other subprojects) etc, not even mentioning external projects. It would be great if we could give some time for our users (and us) to adapt, I agree with @alanbernstein that this would be the perfect time to adapt a deprecation policy.

@jaffee
Copy link
Member Author

jaffee commented Aug 30, 2017

Alright that makes sense. How about we strip everything out of the docs, and add some warnings in Pilosa and client libs for anyone using the feature. After the 0.7.0 release goes out (or whichever one is next), we can remove the feature entirely for the 0.8.0 release.

@yuce
Copy link
Contributor

yuce commented Aug 30, 2017

Great!

@yuce
Copy link
Contributor

yuce commented Sep 25, 2017

@jaffee @travisturner Can we keep the defaults columnID and rowID ? So code which already uses the defaults don't get broken ?

@jaffee
Copy link
Member Author

jaffee commented Sep 25, 2017

Let's still change the defaults but try to do so in a safe way - i.e. deprecate first so that we issue a warning if we see the old label, but still support it as normal, and then remove the support in the next release. As we transition to no labels, let's make sure that Pilosa doesn't break existing meta files - it might be possible for pilosa to read older meta files with the row/col labels and just ignore those fields - the implementer should experiment with this.

@travisturner travisturner mentioned this issue Mar 26, 2018
12 tasks
seebs pushed a commit to seebs/pilosa that referenced this issue Nov 19, 2020
Batch the translation of field keys in results
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants