Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.MySQL, for one, allows creation of fields and tables with names containing spaces, matching reserved words, etc. To use them in queries, they need to be quoted (with backticks for MySQL, double-quotes for Postgres). Right now, Views doesn't do the quoting, so such fields and tables cannot be exposed to Views. The attached patch is a start towards supporting this (I expect there are more areas that will need to be changed to support this).
| Comment | File | Size | Author |
|---|---|---|---|
| views-quotes.patch | 3.62 KB | mikeryan |
Comments
Comment #1
mikeryanFor context, this arose from Table Wizard bug #408094: Handle column names with spaces.
Comment #2
merlinofchaos CreditAttribution: merlinofchaos commentedI'm leery of even looking at this because the Drupal coding standard requires that you avoid reserved words for your tables.
Comment #3
mikeryanThe purpose of the Table Wizard module is to expose non-Drupal tables (such as exports from another CMS, or spreadsheet data) to Views. We can't count on the rest of the world using Drupal coding standards...
Thanks.
Comment #4
esmerel CreditAttribution: esmerel commentedNo work done on this in more than a year.
Comment #5
scotwith1tI'm reactivating this in hopes that someone will be saved the trouble of finding out the data they imported to MYSQL, which accepts spaces in the column names without problem, then went and pulled up in TW with no issues, went to analyzing the data and going to pull up the view and alas, nothing is there...what was more confusing to me was the fact that the pager rendered just fine with the empty text just above it. I agree with Earl though that this should be headed off by TW before it even gets to that point. When you analyze the table with TW, couldn't it simply check for unacceptable characters (like spaces in my case)? I understand the issue now and can completely avoid in the future by naming my data columns correctly, but thought maybe it was worth a shot to reassign, recategorize as a feature request and see what happens. I don't think patching views is the answer though.
Comment #6
x-lette CreditAttribution: x-lette commentedInstead of patching views, tw and whatelse, you could just create a VIEW (within mysql/postgresql/...) with a similar name, selecting all columns and translating bad column names to good ones (SELECT `bad name` AS good_name ...). Given your base table doesn't change it's structure (which in fact would make re-analyzing the table in tw essential) you could handle your table as usual and access it with tw/views nevertheless.
VIEWs are great! :)
Comment #7
13rac1 CreditAttribution: 13rac1 commentedNote: There is a Drupal 8.x feature request for backticks: #1426084: Provide backtick escaping for MySQL in DB abstraction layer.
Does it make this request a dupe?