[support] CCK field database storage discrepancy

[Yves Chedemois]

Fields that :
- are used in several content types
- or allow multiple values
are stored in a content_field_xxx table dedicated to this field.
Other fields (single and non shared) are stored in a per-content-type 
content_type_yyy
I won't enter in the rationale for this here, but that's the pattern.

So obviously something went wrong in the migration of the definition of 
your content types.
Hard to tell what, though, esp. if you're using a patched version of 
content_copy.

Also note that content_copy D5 does not support *updating* the 
definition of a field that already exists on the target site.
Might be different in D6, but I have to say that I didn't actually test it.

The CCK issue queue would be a better place to post this, btw.

Yched


Paul Kim a ecrit le 31/10/2008 18:44:
> I have a content type with several CCK fields. This site goes through 
> the standard dev -> qa -> prod workflow, and so I have at least 3 
> different servers that need updates pushed on a regular basis. I'm doing 
> this through a internal database script that I wrote, and using a 
> patched (with the patch provided in the dbscripts module) 
> content_copy.module for cck changes that allow updates to content types 
> with CCK fields.
>
> I am finding that some fields' content in my dev box is stored as a 
> column in the content_type_xxxx (where xxxx is the content type name) 
> table, whereas they are being stored in the content_field_yyyy (where 
> yyyy is the CCK field name) on the QA machine. For some reason, these 
> fields on the QA machine aren't being properly inserted into the $node 
> variable, and they aren't being saved properly either.
>
> What's the difference between these fields being saved in 
> content_type_xxxx and content_field_yyyy? How do I make sure these CCK 
> fields are stored in the same way across all three databases?
>
> Thanks!
> Paul
>