I have two content types, offices and representatives. These types often have titles that are the same. I have the feed importer for representatives set to update using the title field as key. I import, it shows having created/updated 67 records, but only 42 representatives are shown. I started querying the db to see where these phantom records disappeared to. I noticed a pattern that the missing representatives were the ones that had a preexisting office record with the same title content.
I assume this means that my importer is actually updating the office, thus not honoring the content type selected (representative). If so, this is a major problem which can damage existing date stored in other content types.
The only time I can imagine this should be allowed to happen is if the unique key is the guid identifier, but even then I think the update query should only include nodes of the type set by the importer.
I don't have time to look at the code right now, but if I do later, I will. I searched the issues and didn't see any other reports for this bug.
Comments
Comment #1
rogerrogers commentedI've updated to critical, as I think this bug is fundamental and shouldn't be difficult to fix.
My temporary work-around, since I'm not familiar enough with the module code, is to add a new guid identifier and generate guid data for that field, then use that as key. This avoids overwriting data in the other content type. Messy, yes, but it works.
To replicate the bug:
1. Create two content types;
2. In one type create a value of 'test' for title;
3. Create feed importers for the other type, make the title key, set the importer to UPDATE;
4. Run import, with at least one of the csv values having 'test' as the title.
5. The importer will update the existing record, with the title 'test', even though the importer isn't configured for that node type!
This can definitely be destructive to data.
Comment #2
twistor commentedI believe this was fixed in #1739704: Node lookup by title in Nodeprocessor does not respect nodetype.
Comment #3
twistor commentedCan you verify if your problem was solved?
Comment #4
twistor commentedAfter re-reading the description, this is indeed a duplicate of edit: see above link.
Comment #5
jpstrikesback commentedUnfortunately this issues duplicate link above is linked to itself.
I am seeing something rather alarming which I believe is similar to the OP but it is not restricted to same/similar node titles:
- Site has content of type A
- Feeds is meant to import content type B into Site
- The new content imported by Feeds is sometimes created as new Type B but also randomly overwrites existing content in type A in every import.
I'll start digging tomorrow.
Comment #6
twistor commentedI meant to refer to the link in #2. I will need a lot more information to be able to debug this.
Comment #7
jpstrikesback commentedI've sidestepped the issue by using UUID with feeds. I tried many different uniques nid/name etc (which have their own dangers) so I don't think I can be of more help here, maybe the OP has some more details... my best guess without going back and debugging is that the hash wasn't being checked on update in some scenarios??
Comment #8
twistor commentedAccording to the OP, this issue was indeed fixed in #1739704: Node lookup by title in Nodeprocessor does not respect nodetype.
Comment #8.0
twistor commentedclarified sentence