-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
table_prefix assumes underscore separator #3
Comments
Your request sounds reasonable. However I think the common case is the one where you do want a separator for legibility reasons, so having a table_prefix_separator doesn't look that bad to me. Additionally, it wouldn't break existing code. (Although I doubt that there is much stable production code using HappyBase, since it's still a really young project.) If the separator is part of the prefix, users end up with ugly strings like "foo_" in their code in the common case. HappyBase was designed to hide ugly code (Thrift!) after all! |
Also cleanup error handling in the constructor. Closes issue #3.
Cheers for fixing this! I still think |
Your example is not realistic, since the table_prefix_separator argument is optional. Your example would rather look like this: c = Connection(table_prefix="cleese") …which I think is rather clean. Only if you want a different separator, the code would become a bit more verbose. Btw, I don't see why one would not want an underscore separator between the prefix and the table name itself. Having an underscore in the name makes the web status reports for master and region nodes easier to read, and also the output of commands like Note that the HBase storage model does not penalise long table table names, in contrast to long column names. Column names (both family and qualifier) are written to disk for each |
The table_prefix parameter on Connection is incredibly useful, except it mandates that you use the underscore character as a separator. This is a problem in situations where you don't want any character after your prefix (i.e. it's a set length), or indeed want to use something else.
I propose a change that requires users specify the separator of their choice as art of the prefix. The effort required for users to update their code would be minimal, and the code would benefit from not having a "table_prefix_separator"!
-d
The text was updated successfully, but these errors were encountered: