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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

twistor’s picture

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.

geek-merlin’s picture

Status: Active » Needs review
FileSize
1.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.

twistor’s picture

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?

geek-merlin’s picture

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...?

twistor’s picture

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.

geek-merlin’s picture

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.

geek-merlin’s picture

geek-merlin’s picture

twistor’s picture

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.
twistor’s picture

Status: Needs review » Needs work
geek-merlin’s picture

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.

twistor’s picture

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 :)

geek-merlin’s picture

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?

twistor’s picture

Status: Needs review » Patch (to be ported)
Issue tags: +Needs tests
slefevre1’s picture

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

osopolar’s picture

Version: 7.x-2.x-dev » 6.x-1.0-beta13
Issue summary: View changes
Status: Patch (to be ported) » Needs review
FileSize
1.49 KB

Here is the 6.x backport. It's only for FeedsNodeProcessor because the other processors aren't using hashes at all.

Status: Needs review » Needs work

The last submitted patch, 16: feeds-skip-hash-check-1364116-16.patch, failed testing.

osopolar’s picture

Version: 6.x-1.0-beta13 » 6.x-1.x-dev
Status: Needs work » Needs review

Can't see how the patch causes the test failure - I guess there is something else causing the test to fail. Maybe Changing the version to current dev helps.

geek-merlin’s picture

@osopolar: the patch is frozen to beta and probably won't apply (which is a good feature ;-)

you might want to re-upload it with dev version set !

osopolar’s picture

FileSize
1.41 KB

Patch for dev attached. The patch in #17 applied well, but there it seems that there is something wrong with the locale (language) mapper mapper. Let's see if the problem goes away by itself.

moonray’s picture

Status: Needs review » Reviewed & tested by the community

Works. The line numbers just changed slightly, but the patch still applies.

  • twistor committed c875fd2 on 6.x-1.x authored by osopolar
    Issue #1364116 by axel.rutz, osopolar: Option to skip hash check on re-...
twistor’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: -Needs tests

Looks fine.

Not too much work going on in 6.x these days.

Status: Fixed » Closed (fixed)

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