On Jul 28, 2011, at 6:35, Jonathan Ellis <jbel...@gmail.com> wrote: > I'm talking about data compatibility, which is more important than cli > statement compatibility. > > Consider someone with a python program that creates a CF with the > default settings and inserts some (say) uuid columns and long data. > > If we changed CF creation to default to ascii we would break this program.
If the documentation situation improved, I frankly would have no problem with that, though I think the default should be UTF8. It's not really relevant, though. > > So we had to leave CF comparator defaulting to BytesType, when we > changed the CLI to respect comparator/validator definitions when > parsing user input. > > You could argue that CLI should continue to parse BytesType as ascii > but then how could a user input actual binary data? The lesser evil You mention Python. The user could do it the same way it is done in Python (and other languages, for that matter). A string with escapes for non-printable characters. This is also how the CLI could display the data. > here is to educate users that "if you want to use ascii column names, > that is how you should declare the comparator." There is no evil in offering users UI conventions that are more likely to produce useful results in the face of less than ideal situations. And so long as the default type is something other than ASCII or UTF8 in the name of backwards compatability, these situations will continue to appear and persist. -NK
