Posted by Itangalo on January 12, 2011 at 12:42pm
7 followers
| Project: | Table Manager |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | major |
| Assigned: | inekew |
| Status: | active |
| Issue tags: | table manager |
Issue Summary
I've spent a little time trying to get Data module to work with the view tables created by Webform MySQL Views. It kind of works (as demonstrated in a screencast), but it would be much easier if the table were treated like a standard Drupal table (and not only a view that cannot, from what I understand, be modified).
I suspect that this is quite a big issue to change, but I would still like to raise it.
Thanks for the work on this module.
Comments
#1
It wouldn't be too hard to change the module logic to build an actual table and copy data from webform_submitted_data into it, but that leaves you with the problem of stale data; the table could be refreshed with hook_cron at designated intervals, but on sites with lots of webforms and/or submissions there might be performance issues, and having multiple copies of data lying around the DB just seems wrong.
This is an issue that's come up before with the Data and Table Wizard modules - links collected here for possible workaround inspiration:
http://drupal.org/node/610896
http://drupal.org/node/889306
#2
Hi, nice & nifty module and great screencast!
I wrote the patch in #889306: Allow the designation of a primary key for MySQL views because of a similar issue i had with using "mysql views" in the data.module. As I will be needing this functionality soon, I wrote a small patch that integrates that patch into your module.
It allows for rather seamless data.module- and views-integration, i think, by "convincing" views.module that the "sid"-column is a (valid) primary key. You might have to clear the cache once or twice (see #889306 for the reasons) ...
Best, Fredrik
#3
Here's an extra hi to frega: Hej!
Sorry for not doing so many screencasts in Swedish anymore – I hope you get some Swedish anyway, somehow!
(For jogging your memory – we met at DrupalCon Paris and talked briefly. Unless I'm completely mistaking your nick for someone else.)
//Johan Falk, NodeOne, Sweden
#4
Thanks for rolling this patch, Frega - it works beautifully when the database is not using a table prefix, but for some reason DataTable::adopt() is failing when I try to use it on a database with table prefix. I added TRUE/FALSE tests against the results of DataTable::adopt() and DataTable::drop() and rolled a new patch against the latest version of webform_mysql_views.module. It's still not working, but for devel/debugging purposes it's no longer returning false positives. I'm not too familiar with the internals of the Data module, but there must be some confusion somewhere over the table prefix.
#5
(Hmm, the db_prefix problem has come up before:: #894074: adopt table doesn't support $db_prefix)
#6
Patch applied - thanks again, Frega. I've logged #1027198: Data module integration does not work if Drupal database uses a table prefix to track the table prefix issue; as it seems to be a problem with Data module I've postponed it for the time being.
#7
Hi, module seems to work great, just what I needed, thanks a lot!!
I do receive one user warning:
User warning: sitename.webform_views_test; is not BASE TABLE query: ALTER TABLE webform_views_test_questionnaire CHANGE `submitted` `submitted` INT DEFAULT NULL in _db_query() (line 148 of /pressflow/includes/database.mysqli.inc).
Cannot change field.
Seems to follow from "webform_views_test" being a view, am I right? Can I just ignore this for now?
---
Same question for regarding some "notices" when viewing or saving the schema in the data ui:
Notice: Undefined index: fields in data_ui_views_default_views() (line 50 data/data_ui/data_ui.views_default.inc)
Notice: Undefined index: unsigned in _data_ui_changed() (line 970 data/data_ui/data_ui.admin.inc)
Notice: Undefined index: fields in data_ui_edit_form() (line 482 of data/data_ui/data_ui.admin.inc).
#8
#9
Hi,
I have several users that are supposed to edit the same table manager data. Will this give conflicts if they submit
their data at the same time? Which data will be saved in the table manager data table?
Or is there a better module to use? (creating a view on webform data does not make the data editable
and sheetnode will require too much explaining to do to my users.
I appreciate any answer or I can use any help in pointing me to the right direction (e.g. using a different module)
regards,
Ineke
#10
Changing back the issue title.
@inekew: The title set on comments changes the comment of the issue.
#11
sorry
#12
Apologies but I wrote this module originally for a project using ... Drupal 4.6 I think (maybe even 4.5), I've ported it as each release has come along and rewritten parts of it along the way but, in essence it's still that module... There wasn't any locking functionality (that I was aware of) back when I wrote this - so no, I'm afraid there isn't any locking in this module.
Just to say... I've too much on currently to consider getting back to updating *any* of my modules. You're looking at a break of at least two months (again, AT LEAST!!!) So maybe try looking at the nodetable module instead. I don't know if it directly locks table editing but it does make your table as actual nodes, so you can use another module to accomplish the locking.
Pobster
#13
Thanks Pobster, I'll look into this nodetable module.
and once again sorry for posting it under the wrong issue header..
Regards,
Ineke