I am trying to import users using example module. There is probably some problem with the Content Profile source, which I am trying to use, because it end up with followin error:

Migration failed with source plugin exception: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM content_type_clovek f WHERE (vid = '370')' at line 1

...where content_type_clovek is the machine name of my content profile content type. Can you please point me to the right direction? I am using the latest version of D2D and Migrate. Thanks very much.

Comments

mikeryan’s picture

Status: Active » Postponed (maintainer needs more info)

So, take a look at the content_type_clovek table in your source - is it missing the vid column? As far as I know, CCK's content_type_* tables should always have a vid column.

mikeryan’s picture

Version: » 7.x-2.x-dev
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

No further information provided.

derhasi’s picture

Category: support » bug
Status: Closed (cannot reproduce) » Needs review
FileSize
1.51 KB

I got the same/similar error:

Migration failed with source plugin exception: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to[error]
use near 'FROM 
content_type_profile f
WHERE  (vid = '139')' at line 1

The problem is that the code expects a handable field to be present, but a content profile might e.g only have multi value fields (that are not handable at the moment).

Attached there's a patch that might solve the problem.

mikeryan’s picture

Title: Problem with importing users - SQL error » D6 content_profile import doesn't work with separate field tables
Component: Code » D6-specific
Status: Needs review » Needs work

Ah, so the root cause is not handling the separate field tables for content profiles, as we do for normal nodes. Let's fix that...

mikeryan’s picture

Priority: Normal » Major
derhasi’s picture

Yes the root problem seems to be that the content profile implementation does not (want, @see line 211 && !$info['multiple']) to implement multi value fields.
But we should fix that concrete issue first, as It simply creates a buggy SQ, so users having this problem, still could use d2d. So maybe you could implement the patch, as long as we'll get multivalues in ;)

mikeryan’s picture

Priority: Major » Normal
Status: Needs work » Postponed (maintainer needs more info)

Actually, the code does handle fields whether they're in the separate table or in the main content_type table. I did find that if the content profile type hasn't had any db_storage fields created, there's no content_type_ table, so I committed a patch to make sure the table is there. However, the problem you're reporting seems to indicate that your content_type tables don't have a vid column, and using the latest D6 CCK I cannot reproduce that scenario - is it possible you have an old version of CCK on the D6 site?

mikeryan’s picture

Status: Postponed (maintainer needs more info) » Active

Reproduced the problem, quite by accident - it will happen when all content_profile fields are in separate field tables, the query ends up being "SELECT FROM {content_type_profile} f...". We have to make sure we skip querying if we end up not doing any addField() calls, simple enough (afraid it's too late for the 2.0 release though).

mikeryan’s picture

Status: Active » Fixed

Committed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

claudiu.cristea’s picture

Status: Closed (fixed) » Active

This is still a bug. Fields stored in separate tables (of pattern content_field_<fieldname> are not added to the source records.

This happens because they are filtered out here:


      // The main column for the field should be rendered with
      // the field name, not the column name (e.g., field_foo rather
      // than field_foo_value).
      $field_info = $this->version->getSourceFieldInfo();
      foreach ($field_info as $field_name => $info) {
        if (isset($info['columns']) && !$info['multiple'] && $info['db_storage']) {
          $i = 0;

see $info['db_storage'] condition.

claudiu.cristea’s picture

Title: D6 content_profile import doesn't work with separate field tables » CCK fields stored in own tables not in source row
Assigned: Unassigned » claudiu.cristea

Changed the title.

claudiu.cristea’s picture

Status: Active » Needs review
FileSize
2.31 KB

Here's a patch that add also columns from content_field_* tables.

claudiu.cristea’s picture

This second patch take care about node types that have no CCK table (content_type_*) but only CCK field tables (content_field_*).

claudiu.cristea’s picture

Hmm... It seems that CCK table (content_type_*) is always created even if there's no field inside but only fields stored in the CCK field tables (content_field_*). So, #13 seems the right patch.

mikeryan’s picture

Status: Needs review » Needs work

In the future, please don't reopen long-closed issues, open a fresh issue.

The node.inc query() intentionally only joins the primary field table, because individual tables may have multiple values which on joining would result in multiple rows for a given node. The individual tables are handled in d6.inc - if there's a bug preventing them from getting migrated in your case, the issue will be in DrupalVersion6::getSourceValues() - you'll find the individual field tables queried in the vicinity of line 214.

mikeryan’s picture

Status: Needs work » Closed (fixed)

In working on #1971778: Migrate the image data (alt, title and description) by the Wizard, I have confirmed that as a general rule the content_field_<fieldname> data is included in the source row. Restoring the status of this issue - if you can reproduce and describe a specific issue with migrating field data, please open a fresh issue.