Failed Station Schedule Update
tim.plunkett - May 25, 2009 - 02:52
| Project: | Station |
| Version: | 6.x-2.x-dev |
| Component: | Schedule |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Description
This is my error message when I ran update.php, station_schedule.module update 6001:
Failed: INSERT INTO content_field_station_program_dj (nid, vid) SELECT n.nid, n.vid FROM station_dj f INNER JOIN {node} n ON f.program_nid = n.program_nid WHERE NOT EXISTS ( SELECT * FROM content_field_station_program_dj t WHERE f.program_nid = t.program_nid)
Failed: UPDATE content_field_station_program_dj t INNER JOIN station_dj f ON t.program_nid = f.program_nid SET t.field_station_program_dj_uid = f.uidI see two issues here.
One is that it tries to match station.dj.program_nid to content_field_station_program_dj.program_nid when it should be content_field_station_program_dj.nid
Second, it does not allow for cases where two DJs are assigned to the same program.
The first issue was easily [yet sloppily] corrected.
The second issue seems to have been theoretically addressed in the database structure, but not in the code.
I am not sure how to correct the second issue.
Tim Plunkett
WKDU 91.7fm
#1
There should have been some actually errors from the database. Did you capture those?
The second part isn't the case. The schema is quite capable of having multiple DJs assigned to a program. The table names aren't hard coded--they're coming from CCK--so I'm not sure why those wouldn't be correct.
The migration is done as a two step process of INSERT ... WHERE NOT EXIST/UPDATE because it's possible that a record might already exists. It would be really helpful to get a copy of your database pre-upgrade to try debugging.
#2
What I meant by the first part was that
$join_colis set toprogram_nidduring the migration, and while that is the appropriate column name for the tablestation_dj, the new CCK table usesnid.To remedy this I added another entry to $migrations.
For the second part, you are right, the schema does allow multiple DJs through the use of
content_field_station_program_dj.delta. My point is that neither INSERT nor UPDATE make use of this.Attached are both the original table and the new table.
- Tim
#3
#4
Duh. You're totally right on the UPDATE not doing anything useful.
#5
The bad join you'd noticed was only present in the schedule update but in the process of debugging that I noticed that the tables names weren't being {} quoted for db prefixing in the schedule, program or playlist updates.
I'm hoping you've got a pre-update database you could test this out on.
#6
If he doesn't, I do. I ran into the same issue when doing a dry run upgrade this weekend on my dev box. I'll see if I can do quick test tonight.
#7
Update worked for me. Didn't see any station-related errors. Now to deal with the audio module and cache errors during 5 to 6 upgrade. I'll post the audio upgrade issue in its issue queue.
#8
great, well it's a clear improvement so i've committed it. if there are further problems we can address those when they're identified.
#9
UNFIXED: see http://drupal.org/node/357519#comment-1671530
#10
okay totally untested but i think something like this should work.
#11
I'm still a bit confused by this, because when I manually added a couple DJs in, I solved my problem by using
content_field_station_program_dj.delta, and this new patch still doesn't seem to address that at all.#12
ah right the delta is the source for the key conflict... for some reason i was thinking the problem was with the value.
#13
Also, I'm noticing some severe inconsistencies, mostly revolving around
content_field_station_program_dj.vidandcontent_field_station_program_dj.nid. The table has vid as the primary key, not sure if that's intentional.My issue seems to be when nid!=vid.
The update seems to assume that they are the same.
#14
Bumping this, it's essential for an upgrade from 5->6.
#15
bumping. i really need to revisit this before 2.x goes stable.
#16
tim, any chance you've still got a backup of your db to test this against? otherwise it seems fine with my test data.
#17
went a head and committed this after some more testing. i think i'll roll a beta release and see if i can get anyone to test it.
#18
Automatically closed -- issue fixed for 2 weeks with no activity.