Feeds saves a hash of source row data and skips processing the hash is the same. However, I'd like to be able to force an update for a particular batch job. Even if the source row hasn't changed, I may have changed the processing behavior with hook_feeds_after_parse() or Feeds Tamper module settings.

Comments

If you have changed the way the items get parsed then the hash of the items will change.

As a note, if you want to re-run an import you can delete the last two mappings and re-add them in the opposite order. Not ideal, I know, but can be useful.

Still a valid feature request.

Status:Active» Needs review
StatusFileSize
new1.65 KB

>If you have changed the way the items get parsed then the hash of the items will change.
Source code says: hash comes from source data and unchanged hash saves us from forther processing - which is a good thing in production.

I think this is an important DX issue and iterating a feed is a PITA without that so raising prio (feel free to readjust if i'm too self centered).

Here is a straightforward implementation which worksforme, please test.

As soon as this gets committed i will simplify my pending patch in #1152940: Feeds term import with hierarchy and weight where we needed the same for a two-pass import.

Status:Needs review» Needs work

#1152940: Feeds term import with hierarchy and weight got committed. Can you re-work this patch to remove the Term specific functionality?

Status:Needs work» Needs review

> Can you re-work this patch to remove the Term specific functionality?
I don't see term specific functionality in #2...?

Status:Needs review» Needs work

FeedsTermProcessor has its own version of this patch added in #1152940: Feeds term import with hierarchy and weight. That code should be re-factored to use this patch.

Status:Needs work» Needs review

Patch in minisprint branch:
* Implemented 1364116: Option to skip hash check on re-import - i reworked that to stay compatible for most scenarios by letting getHash return a fake hash so other importers can inherit that.
* Reverted force-update config in #1152940 as skip-hash-check #1364116 implements that
* also this fixes #1698076: Force update for TermProcessor should default to FALSE.

This should actually be 2 settings. Forced updating should be set on a per-source basis.

  1. Allow forced updating, on the importer page.
  2. On the source page, "Force update" checkbox.

Status:Needs review» Needs work

Status:Needs work» Needs review

I don't agree moving the "force update" setting from "importer" to "source".
At least i don't understand your background.
For me this setting is an extension to the "update existing content" setting and so global to the processor.
Having this per source is a different issue to me which i now see no use case.

Status:Needs review» Needs work

@axel, I concede the point. My thought is that it's most useful for debuggin/developing, rather than a long term solution. I agree though, that it's more of an extension to "Update existing". So, then why don't we put it in that list :)

Status:Needs work» Needs review

> it's more of an extension to "Update existing". So, then why don't we put it in that list :)

I already thought about that but "skip hash check" is orthogonal to the "update / replace" setting.

Incorporating in the list would multiply that out to 5 options like this reworded)

Unique target behavior:
* Create new items on every import
* Replace existing items on every import
* Update existing items (slower than replacing them, but keeps unmapped fields) on every import
* Replace existing items if source item changed
* Update existing items (slower than replacing them, but keeps unmapped fields) if source item changed

old wording:

* Do not update existing nodes
* Do not update existing nodes & [X] Skip hash check
* Update existing nodes (slower than replacing them) & [X] Skip hash check
* Do not update existing nodes & [ ] Skip hash check
* Update existing nodes (slower than replacing them) & [ ] Skip hash check

what do you think about this?

Status:Needs review» Patch (to be ported)
Issue tags:+Needs tests

I think it would be handy to have this option on the import page of each feed. We ran into a situation where we had a feed for a content type that was in a features module. We added some fields to the feature, but our feeds ran from cron before we updated the mapping, and feeds considered the nodes to have been updated even though it didn't care about the new fields when it ran.

It would have been convenient to run the feed on its /import page, checked the box to ignore hashes, and then just go on our merry way. We don't want the hashes skipped on each import, just when we screw things up :P