I've got a "reservation" node type with a date field with both start and end times. There's a node ref field, and I've got some resource nodes to test with. However, when I try to create a reservation node in this configuration, I'm getting:
Unknown column 'field_date_value' in 'where clause' query: _resource_conflict_get_overlaps SELECT nid FROM do_test_content_type_reservation WHERE('2008-08-24T14:00:00' >= field_date_value AND '2008-08-24T14:00:00' < field_date_value2) OR('2008-08-24T14:00:00' > field_date_value AND '2008-08-24T14:00:00' <= field_date_value2) OR('2008-08-24T14:00:00' <= field_date_value AND '2008-08-24T14:00:00' >= field_date_value2)
Haven't debugged it at all yet, but I wanted to report it. I don't think this is duplicate with #289346: Dates have to have a required end fields since I'm sure I have start/end times on this node type.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 294578_db_table_prefix.patch | 1.1 KB | dww |
Comments
Comment #1
dwwOk, here's what appears to be going wrong. On my site, I've got multiple node types that have a "date" field. When I created the reservation node type, I just added my existing date field to it. So, instead of having the date fields directly in {content_type_reservation}, my date data lives in {content_field_date}. _resource_conflict_get_overlaps() assumes the data lives in the {content_type_*} table, but that's not always true. Seems like there must be a real CCK API for getting this stuff so we don't have to know what table to query ourselves. I'll dig a little deeper.
Comment #2
dwwRight, seems like we need to use content_database_info() for this.
Comment #3
deviantintegral commentedSounds right. I think the same API will also be used for getting the DB columns, so they don't have to be hard-coded.
Comment #4
deviantintegral commentedI've fixed this in CVS. Let me know if it works for you.
--Andrew
Comment #5
dwwCool, thanks! It's almost working now. However, to flesh out bugs my test site is using a DB table prefix. The way you're trying to use {} around the table name confuses the table prefixer, since you've got whitespace between { and the table name and that results in "do_test_ content_field_date" in the final SQL, which obviously confuses the DB. Attached patch solves it for me. Any objections, or should I go ahead and commit this?
Thanks,
-Derek
Comment #6
dwwIn IRC, deviantintegral said he liked this, so I committed to DRUPAL-5--2.
Comment #7
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.