Colon in tokens using Search api Solr views

After some research in the searchapi code:

      $parts = explode(':', $key);
...
      $table[$key]['title'] = $name;

Basically you can't use ":" as the field names.

Then this should at least be documented for hook_views_data(). But would it be so hard to fix it? You'd just have to do preg_replace() calls before using the field name for tokens, theme templates or any other stuff that might not be able to handle colons.
All the rest of Views has no problems with colons and, while no big improvement (but also not very hard to do, as far as I can see), this would further increase flexibility.

Otherwise, as said, please document this and I'll just work around it in my module. (Please don't move this issue there, though there is already #1018384: Fix views field names to not contain colons.)

Why should this be documented in hook_views_data? Field names have to be things you could legally have in a database field name. I'm pretty sure : is not legal in a database field name.

In Views 3, fields and tables don't have to be related to the database, therefore it's really not self-evident (anymore) that field names should follow the same restrictions as for the database.

Could you at least tell me what characters are allowed in field names, if you don't intend to document them?

Subscribing

"anything legally allowed in a database field name"

If you like, I can go to http://letmegooglethatforyou.com and look up what ANSI sql allows but you're capable of googling, right?

Oh also this is a pretty good indicator of what is legal:

The colons also prevent me from overriding the field with a custom template, since I can't use colons in the template file name.

If you want your fields to be templatable, you need to use values that are acceptable in function names. That's actually more strict, since that basically limits you to alphanumeric and _.

OK, that's good to know, thanks! As said, Views 3 is in no way specific to databases anymore, and I doubt that special characters would generally pose any problems. (I know for a fact that colons work in most cases.) Restrictions like those for templates and tokens (if you always use the raw field name for those) are far more relevant in this case.
Therefore, thanks for your answer!
I still think that this should be documented somewhere, though. Especially if you now say yourself that the requirements are actually more strict than those for DB field names (even though I think that the DB abstraction layer also can't handle more than alphanumerics and underscores).

Move it as documentation task.

Added a note to style.html about restrictions on names.