I just ran into a Drupal gotcha. Here's the situation. I coded db queries for nodes and blocks using the hard-coded field file_path which is part of the content-type story-image. My queries referenced content_type_story_image.field_story_file_path_value and it was working fine.
However today I added a second content type, fairy-tale-image which as one of its fields uses the existing field file_path. This caused the file_path field to move into its own table, content_field_file_path. Now I've changed the queries but am thinking there must be a more intelligent way I could've done these queries, like going through Drupal's api and not getting caught on this snag.
Can anyone point me in the right direction to learn how to do that?
Marty
Marty,
Views module. It's a dynamic query builder. It is very, very smart.
http://drupal.org/project/views
As a coder you might find yourself working hard to get out of the way of Drupal and its ecosystem of modules.
Take out your coder chops on writing a new module for contrib, not on writing custom code for a client project.
best,
Shai
On Thu, Sep 15, 2011 at 9:43 PM, Marty Landman mlandman@face2interface.comwrote:
I just ran into a Drupal gotcha. Here's the situation. I coded db queries for nodes and blocks using the hard-coded field file_path which is part of the content-type story-image. My queries referenced content_type_story_image.field_story_file_path_value and it was working fine.
However today I added a second content type, fairy-tale-image which as one of its fields uses the existing field file_path. This caused the file_path field to move into its own table, content_field_file_path. Now I've changed the queries but am thinking there must be a more intelligent way I could've done these queries, like going through Drupal's api and not getting caught on this snag.
Can anyone point me in the right direction to learn how to do that?
Marty
-- http://drupal.org/project/personal_notes https://addons.mozilla.org/af/firefox/addon/181910/
-- [ Drupal support list | http://lists.drupal.org/ ]
Another option is using the CCK API to dynamically determine the table info for a given field.
drewish has a great article on it at http://drewish.com/content/2010/06/correctly_accessing_cck_fields_in_sql_que..., and a tool to help you determine the correct values to use at http://drewish.com/tools/cck-query.
Steve
On Sep 15, 2011, at 6:55 PM, Shai Gluskin wrote:
Marty,
Views module. It's a dynamic query builder. It is very, very smart.
http://drupal.org/project/views
As a coder you might find yourself working hard to get out of the way of Drupal and its ecosystem of modules.
Take out your coder chops on writing a new module for contrib, not on writing custom code for a client project.
best,
Shai
On Thu, Sep 15, 2011 at 9:43 PM, Marty Landman mlandman@face2interface.com wrote: I just ran into a Drupal gotcha. Here's the situation. I coded db queries for nodes and blocks using the hard-coded field file_path which is part of the content-type story-image. My queries referenced content_type_story_image.field_story_file_path_value and it was working fine.
However today I added a second content type, fairy-tale-image which as one of its fields uses the existing field file_path. This caused the file_path field to move into its own table, content_field_file_path. Now I've changed the queries but am thinking there must be a more intelligent way I could've done these queries, like going through Drupal's api and not getting caught on this snag.
Can anyone point me in the right direction to learn how to do that?
Marty
-- http://drupal.org/project/personal_notes https://addons.mozilla.org/af/firefox/addon/181910/
-- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
Thank you Steve and Shai. Both good advice it looks like for me to work on.
At 10:29 PM 9/15/2011, Steve Edwards wrote:
Another option is using the CCK API to dynamically determine the table info for a given field.
drewish has a great article on it at http://drewish.com/content/2010/06/correctly_accessing_cck_fields_in_sql_querieshttp://drewish.com/content/2010/06/correctly_accessing_cck_fields_in_sql_que..., and a tool to help you determine the correct values to use at http://drewish.com/tools/cck-queryhttp://drewish.com/tools/cck-query.
Steve
On Sep 15, 2011, at 6:55 PM, Shai Gluskin wrote:
Marty,
Views module. It's a dynamic query builder. It is very, very smart.
http://drupal.org/project/viewshttp://drupal.org/project/views
As a coder you might find yourself working hard to get out of the way of Drupal and its ecosystem of modules.
Take out your coder chops on writing a new module for contrib, not on writing custom code for a client project.
best,
Shai
On Thu, Sep 15, 2011 at 9:43 PM, Marty Landman <mailto:mlandman@face2interface.commlandman@face2interface.com> wrote: I just ran into a Drupal gotcha. Here's the situation. I coded db queries for nodes and blocks using the hard-coded field file_path which is part of the content-type story-image. My queries referenced content_type_story_image.field_story_file_path_value and it was working fine.
However today I added a second content type, fairy-tale-image which as one of its fields uses the existing field file_path. This caused the file_path field to move into its own table, content_field_file_path. Now I've changed the queries but am thinking there must be a more intelligent way I could've done these queries, like going through Drupal's api and not getting caught on this snag.
Can anyone point me in the right direction to learn how to do that?
Marty
-
Marty Landman -
Shai Gluskin -
Steve Edwards