Posted by mikeryan on March 22, 2009 at 10:50pm
5 followers
Jump to:
| Project: | Table Wizard |
| Version: | 6.x-1.3 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
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).
| Attachment | Size |
|---|---|
| views-quotes.patch | 3.62 KB |
Comments
#1
For context, this arose from Table Wizard bug #408094: Handle column names with spaces.
#2
I'm leery of even looking at this because the Drupal coding standard requires that you avoid reserved words for your tables.
#3
The 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.
#4
No work done on this in more than a year.
#5
I'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.
#6
Instead 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! :)