search

jplindstrom / p5-DBIx-Class-BatchUpdate

Perl module to update batches of DBIC rows with as few queries as possible
0 stars 1 forks source link

Dangerous assumption of immutable PK #3

Closed ribasushi closed 8 years ago

ribasushi commented 8 years ago

Sorry that I didn't notice this the first time around. This is not... ideal. What you want to do is to fall back to the original one-by-one update() logic when any part of the PK (which could be multicolumn) is dirty. Perhaps with a warning (yada-yada BatchUpdate ineffective).

Doing anything else is likely to result in bugs that will be extraordinarily hard to diagnose.

jplindstrom commented 8 years ago

If the PK is dirty, then it will be included in the batch_key, so that would lead to individual updates.

This approach doesn't at all work with multi-col PKs since it's a simple -in clause. What's the simplest way to detect that the PK isn't a single column?

jplindstrom commented 8 years ago

Ahh, I see, if the PK has changed, then it wouldn't be matched in the where clause.

ribasushi commented 8 years ago

Ahh, I see, if the PK has changed, then it wouldn't be matched in the where clause.

Precisely! DBIC internally has ways to deal with this, hence it'd be easiest to just "fall through back to DBIC".

What's the simplest way to detect that the PK isn't a single column?

You basically loop through ...->result_source->primary_columns which gives you a list of names to avoid.

jplindstrom commented 8 years ago

I don't have the time to spend right now to fix this in a solid way so I'm going to pull a MySQL and document the caveats.

jplindstrom commented 8 years ago

Documented and checks for dirty pk values.

This is not a case where you'd randomly update the PK and it works but slowly. You'd want to know.

And if you update the PK for all rows, BatchUpdate wouldn't work anyway.