-
Notifications
You must be signed in to change notification settings - Fork 232
Proposal: Remove row and column labels #752
Comments
Should we codify a deprecation policy? This would be a good place to start. |
I propose we change it to |
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. |
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 ? |
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 |
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. |
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. |
Great! |
@jaffee @travisturner Can we keep the defaults |
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. |
Batch the translation of field keys in results
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>)
orBitmap(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.
The text was updated successfully, but these errors were encountered: