New CCK field not found in mysql
I've created a new field for a CCK type and it works fine in my drupal site. My problem is that it does not show up in mysql command line interface or with phpmyadmin. This is confusing to me. I can modify, add and delete data using the edit node function when viewing a page, so I know the data is somewhere, however, I wish to do a batch load of this field with mysql.
I found where the data went by exporting the sites database. Rather than create a new table named content_field_street_name, as I would have expected, it created content_type_[content_type_name]. This table has fields: vid, nid and field_street_name_value. I'm about out of time today but I wonder what would've happened had I added two new fields to this CCK type. On Fri, 2009-11-20 at 12:07 -0800, Scott wrote:
I've created a new field for a CCK type and it works fine in my drupal site. My problem is that it does not show up in mysql command line interface or with phpmyadmin. This is confusing to me. I can modify, add and delete data using the edit node function when viewing a page, so I know the data is somewhere, however, I wish to do a batch load of this field with mysql.
CCK is black magic... better not to try and decipher the db structure which at times seems kind of arbitrary to me. The better way is to write a fn that loops thru the nodes you want to batch add to, do a node_load() on them, modify the desired fields, then node_save(). HTH, -Dom On Nov 20, 2009, at 1:07 PM, Scott wrote:
I found where the data went by exporting the sites database. Rather than create a new table named content_field_street_name, as I would have expected, it created content_type_[content_type_name]. This table has fields: vid, nid and field_street_name_value. I'm about out of time today but I wonder what would've happened had I added two new fields to this CCK type.
On Fri, 2009-11-20 at 12:07 -0800, Scott wrote:
I've created a new field for a CCK type and it works fine in my drupal site. My problem is that it does not show up in mysql command line interface or with phpmyadmin. This is confusing to me. I can modify, add and delete data using the edit node function when viewing a page, so I know the data is somewhere, however, I wish to do a batch load of this field with mysql.
-- [ Drupal support list | http://lists.drupal.org/ ]
Absolutely. One of the things you'll find to is that where data is stored will shift on you depending on whether the field is isolated to one node type only or if it is shared, etc.. As Domenic said, it really is best to use the regular node api for this sort of thing rather than try to cram it in via direct SQL queries against the DB. On Fri, Nov 20, 2009 at 4:41 PM, Domenic Santangelo <domenics@gmail.com>wrote:
CCK is black magic... better not to try and decipher the db structure which at times seems kind of arbitrary to me.
The better way is to write a fn that loops thru the nodes you want to batch add to, do a node_load() on them, modify the desired fields, then node_save().
HTH, -Dom
On Nov 20, 2009, at 1:07 PM, Scott wrote:
I found where the data went by exporting the sites database. Rather than create a new table named content_field_street_name, as I would have expected, it created content_type_[content_type_name]. This table has fields: vid, nid and field_street_name_value. I'm about out of time today but I wonder what would've happened had I added two new fields to this CCK type.
On Fri, 2009-11-20 at 12:07 -0800, Scott wrote:
I've created a new field for a CCK type and it works fine in my drupal site. My problem is that it does not show up in mysql command line interface or with phpmyadmin. This is confusing to me. I can modify, add and delete data using the edit node function when viewing a page, so I know the data is somewhere, however, I wish to do a batch load of this field with mysql.
-- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
Hi William, Domenic, Would this also apply to reading/setting the possible values in a radio-button list of a CCK field [used by then many Nodes]? Wouldn't that just be in one single location? Thanks for your input! Kindly, Sebastian. William Smith wrote:
Absolutely. One of the things you'll find to is that where data is stored will shift on you depending on whether the field is isolated to one node type only or if it is shared, etc.. As Domenic said, it really is best to use the regular node api for this sort of thing rather than try to cram it in via direct SQL queries against the DB.
On Fri, Nov 20, 2009 at 4:41 PM, Domenic Santangelo <domenics@gmail.com <mailto:domenics@gmail.com>> wrote:
CCK is black magic... better not to try and decipher the db structure which at times seems kind of arbitrary to me.
The better way is to write a fn that loops thru the nodes you want to batch add to, do a node_load() on them, modify the desired fields, then node_save().
HTH, -Dom
On Nov 20, 2009, at 1:07 PM, Scott wrote:
> I found where the data went by exporting the sites database. Rather > than create a new table named content_field_street_name, as I would > have > expected, it created content_type_[content_type_name]. This table has > fields: vid, nid and field_street_name_value. I'm about out of time > today but I wonder what would've happened had I added two new fields > to > this CCK type. > > > On Fri, 2009-11-20 at 12:07 -0800, Scott wrote: >> I've created a new field for a CCK type and it works fine in my >> drupal >> site. My problem is that it does not show up in mysql command line >> interface or with phpmyadmin. This is confusing to me. I can >> modify, >> add and delete data using the edit node function when viewing a >> page, so >> I know the data is somewhere, however, I wish to do a batch load of >> this >> field with mysql. >> > > -- > [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
Hello again, It's very appropriate to see this thread right now... So I've found the values in the mySQL database, and they are indeed spread between: content_node_field and content_field_[name_of_field] the pairs of human readable values, and system values are also in two different places, with only the machine names in the content_field_[name_of_field], ug. Since this arrangement seems to make things really convoluted, I would like to ask if it would make more sense for me to create my own radio/checkbox system, and to bypass the CCK system entirely? [Especially if I want my module to function as a stand-alone for this, future and possibly the Drupal community at large.] What I am trying to accomplish is: 1. Content Admin can select from a radiobox selection, which page they want the content on 2. Content Admin can add/remove options from the radio boxes [they only see the human-readable formats], which in turn automatically adds/removes pages; from their perspective the two are fundamentally the same. What goes on behind the scene: When they add/remove options from the radio boxes, it auto generates a system-readable name [removes spaces with '_' and '&' with 'and' etc.), and then also adds/removes the respective menu item that matches the same machine_name as the radio selection, in the format: [Panel_Name]/[radio_select_option] So that the Panels page: Panel_Name can be called and passed the argument: [radio_select_option]. That way, they never need to see the machine names, they never need to admin two places to do one thing [adding removing menus and new options appearing in the radio buttons is synonymous]. Because as it is right now, as soon as one uses Views+Panels, there is no way that a non-admin can add (remove) a new menu item easily without a lot of hand-holding. I'm learning quite fast all of the system, and so I think I am going in the right direction; but I am still very new to not only Drupal, but also PHP/mySQL, --- So what I am planning on doing now is bypassing CCK altogether and making my own table in the DB specifically for this purpose... but before I go down that road, I just wanted to check that this is indeed the sane way to do it...? BTW: I realize that doing this will mean I need to also manually add the new radio box option to the $node_form too. Thank you kindly for your time and your reply, Sebastian. sebastian wrote:
Hi William, Domenic,
Would this also apply to reading/setting the possible values in a radio-button list of a CCK field [used by then many Nodes]? Wouldn't that just be in one single location?
Thanks for your input!
Kindly,
Sebastian.
William Smith wrote:
Absolutely. One of the things you'll find to is that where data is stored will shift on you depending on whether the field is isolated to one node type only or if it is shared, etc.. As Domenic said, it really is best to use the regular node api for this sort of thing rather than try to cram it in via direct SQL queries against the DB.
On Fri, Nov 20, 2009 at 4:41 PM, Domenic Santangelo <domenics@gmail.com <mailto:domenics@gmail.com>> wrote:
CCK is black magic... better not to try and decipher the db structure which at times seems kind of arbitrary to me.
The better way is to write a fn that loops thru the nodes you want to batch add to, do a node_load() on them, modify the desired fields, then node_save().
HTH, -Dom
On Nov 20, 2009, at 1:07 PM, Scott wrote:
> I found where the data went by exporting the sites database. Rather > than create a new table named content_field_street_name, as I would > have > expected, it created content_type_[content_type_name]. This table has > fields: vid, nid and field_street_name_value. I'm about out of time > today but I wonder what would've happened had I added two new fields > to > this CCK type. > > > On Fri, 2009-11-20 at 12:07 -0800, Scott wrote: >> I've created a new field for a CCK type and it works fine in my >> drupal >> site. My problem is that it does not show up in mysql command line >> interface or with phpmyadmin. This is confusing to me. I can >> modify, >> add and delete data using the edit node function when viewing a >> page, so >> I know the data is somewhere, however, I wish to do a batch load of >> this >> field with mysql. >> > > -- > [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
Hmm, actually if I make my own radio select option, maybe that will make it also complex to add it to the list of available arguments in Views and Panels? More so than figuring our a way to access the CCK field directly? My apologies if I am unaware of all the nuances involved in this module's development. Thank you kindly, Sebastian. sebastian wrote:
Hello again,
It's very appropriate to see this thread right now... So I've found the values in the mySQL database, and they are indeed spread between:
content_node_field
and
content_field_[name_of_field]
the pairs of human readable values, and system values are also in two different places, with only the machine names in the content_field_[name_of_field], ug.
Since this arrangement seems to make things really convoluted, I would like to ask if it would make more sense for me to create my own radio/checkbox system, and to bypass the CCK system entirely?
[Especially if I want my module to function as a stand-alone for this, future and possibly the Drupal community at large.]
What I am trying to accomplish is:
1. Content Admin can select from a radiobox selection, which page they want the content on
2. Content Admin can add/remove options from the radio boxes [they only see the human-readable formats], which in turn automatically adds/removes pages; from their perspective the two are fundamentally the same.
What goes on behind the scene:
When they add/remove options from the radio boxes, it auto generates a system-readable name [removes spaces with '_' and '&' with 'and' etc.), and then also adds/removes the respective menu item that matches the same machine_name as the radio selection, in the format: [Panel_Name]/[radio_select_option] So that the Panels page: Panel_Name can be called and passed the argument: [radio_select_option].
That way, they never need to see the machine names, they never need to admin two places to do one thing [adding removing menus and new options appearing in the radio buttons is synonymous].
Because as it is right now, as soon as one uses Views+Panels, there is no way that a non-admin can add (remove) a new menu item easily without a lot of hand-holding.
I'm learning quite fast all of the system, and so I think I am going in the right direction; but I am still very new to not only Drupal, but also PHP/mySQL, ---
So what I am planning on doing now is bypassing CCK altogether and making my own table in the DB specifically for this purpose... but before I go down that road, I just wanted to check that this is indeed the sane way to do it...?
BTW: I realize that doing this will mean I need to also manually add the new radio box option to the $node_form too.
Thank you kindly for your time and your reply,
Sebastian.
sebastian wrote:
Hi William, Domenic,
Would this also apply to reading/setting the possible values in a radio-button list of a CCK field [used by then many Nodes]? Wouldn't that just be in one single location?
Thanks for your input!
Kindly,
Sebastian.
William Smith wrote:
Absolutely. One of the things you'll find to is that where data is stored will shift on you depending on whether the field is isolated to one node type only or if it is shared, etc.. As Domenic said, it really is best to use the regular node api for this sort of thing rather than try to cram it in via direct SQL queries against the DB.
On Fri, Nov 20, 2009 at 4:41 PM, Domenic Santangelo <domenics@gmail.com <mailto:domenics@gmail.com>> wrote:
CCK is black magic... better not to try and decipher the db structure which at times seems kind of arbitrary to me.
The better way is to write a fn that loops thru the nodes you want to batch add to, do a node_load() on them, modify the desired fields, then node_save().
HTH, -Dom
On Nov 20, 2009, at 1:07 PM, Scott wrote:
> I found where the data went by exporting the sites database. Rather > than create a new table named content_field_street_name, as I would > have > expected, it created content_type_[content_type_name]. This table has > fields: vid, nid and field_street_name_value. I'm about out of time > today but I wonder what would've happened had I added two new fields > to > this CCK type. > > > On Fri, 2009-11-20 at 12:07 -0800, Scott wrote: >> I've created a new field for a CCK type and it works fine in my >> drupal >> site. My problem is that it does not show up in mysql command line >> interface or with phpmyadmin. This is confusing to me. I can >> modify, >> add and delete data using the edit node function when viewing a >> page, so >> I know the data is somewhere, however, I wish to do a batch load of >> this >> field with mysql. >> > > -- > [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
The content_database_info() function gives you the storage information you need to build your custom queries. You can do something like: $field = content_fields($field_name); $db_info = content_database_info($field); $sql = db_fetch_array(db_query('SELECT nid FROM {'. $db_info['table'] . '} WHERE '. $db_info['columns']['value'] .' = %d',$product_id)); See the PHPdoc for more details. Yves Chedemois William Smith a ecrit le 20/11/2009 22:49:
Absolutely. One of the things you'll find to is that where data is stored will shift on you depending on whether the field is isolated to one node type only or if it is shared, etc.. As Domenic said, it really is best to use the regular node api for this sort of thing rather than try to cram it in via direct SQL queries against the DB.
On Fri, Nov 20, 2009 at 4:41 PM, Domenic Santangelo <domenics@gmail.com <mailto:domenics@gmail.com>> wrote:
CCK is black magic... better not to try and decipher the db structure which at times seems kind of arbitrary to me.
The better way is to write a fn that loops thru the nodes you want to batch add to, do a node_load() on them, modify the desired fields, then node_save().
HTH, -Dom
On Nov 20, 2009, at 1:07 PM, Scott wrote:
> I found where the data went by exporting the sites database. Rather > than create a new table named content_field_street_name, as I would > have > expected, it created content_type_[content_type_name]. This table has > fields: vid, nid and field_street_name_value. I'm about out of time > today but I wonder what would've happened had I added two new fields > to > this CCK type. > > > On Fri, 2009-11-20 at 12:07 -0800, Scott wrote: >> I've created a new field for a CCK type and it works fine in my >> drupal >> site. My problem is that it does not show up in mysql command line >> interface or with phpmyadmin. This is confusing to me. I can >> modify, >> add and delete data using the edit node function when viewing a >> page, so >> I know the data is somewhere, however, I wish to do a batch load of >> this >> field with mysql. >> > > -- > [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
CCK only creates content_field_xxxx when that field is shared between two or more content types. Otherwise, it just adds a column to content_type_yyyy. -----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Sent: Friday, November 20, 2009 1:07 PM To: support@drupal.org Subject: Re: [support] New CCK field not found in mysql I found where the data went by exporting the sites database. Rather than create a new table named content_field_street_name, as I would have expected, it created content_type_[content_type_name]. This table has fields: vid, nid and field_street_name_value. I'm about out of time today but I wonder what would've happened had I added two new fields to this CCK type. On Fri, 2009-11-20 at 12:07 -0800, Scott wrote:
I've created a new field for a CCK type and it works fine in my drupal site. My problem is that it does not show up in mysql command line interface or with phpmyadmin. This is confusing to me. I can modify, add and delete data using the edit node function when viewing a page, so I know the data is somewhere, however, I wish to do a batch load of this field with mysql.
-- [ Drupal support list | http://lists.drupal.org/ ]
..unless it's multiple values. It really is best to avoid direct queries of CCK fields. Sometimes fields on the same type will be in content_type_FOO tables or in content_field_FIELD_FOO. If you are importing alot of data, I can't say enough good things about the Tablewizard and Migrate modules. http://drupal.org/project/tw http://drupal.org/project/migrate BTW, the technic that Domenic described is what Migrate module does under the hood. -Mikey P __________________ Michael Prasuhn 503.512.0822 office 503.539.3864 cell 503.661.7574 home mike@mikeyp.net http://mikeyp.net On Nov 20, 2009, at 1:45 PM, Paul Kim wrote:
CCK only creates content_field_xxxx when that field is shared between two or more content types. Otherwise, it just adds a column to content_type_yyyy.
-----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Sent: Friday, November 20, 2009 1:07 PM To: support@drupal.org Subject: Re: [support] New CCK field not found in mysql
I found where the data went by exporting the sites database. Rather than create a new table named content_field_street_name, as I would have expected, it created content_type_[content_type_name]. This table has fields: vid, nid and field_street_name_value. I'm about out of time today but I wonder what would've happened had I added two new fields to this CCK type.
On Fri, 2009-11-20 at 12:07 -0800, Scott wrote:
I've created a new field for a CCK type and it works fine in my drupal site. My problem is that it does not show up in mysql command line interface or with phpmyadmin. This is confusing to me. I can modify, add and delete data using the edit node function when viewing a page, so I know the data is somewhere, however, I wish to do a batch load of this field with mysql.
-- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
participants (7)
-
Domenic Santangelo -
Michael Prasuhn -
Paul Kim -
Scott -
sebastian -
William Smith -
Yves Chedemois