Corrected object comparison with partial nil values.

[Jack12816]

Follow up to: #617

- What is it good for

PR #617 broke support for comparing records with partially nil-values within the composite primary key.

- What I did

This PR fixes the issue by just swapping id.all? {|key| !key.nil?} to id.any? and adds tests for it.

Enumerable#any? If the block is not given, Ruby adds an implicit block of { |obj| obj } that will cause any? to return true if at least one of the collection members is not false or nil.

I just ran the tests locally with PostgreSQL, and blindly added the schema changes for the other databases. When CI runs I will fix them if needed.

Ah and sorry for the diff glitches, but the code base does not enforce any automatic linting and I'm used to not mix tabs/spaces and/or having trailing whitespaces (automatic fixes on my side).

- A picture of a cute animal (not mandatory but encouraged)

[cfis]

Oh sorry about the breakage and thanks for the PR. But it seems to include a lot of additional, unrelated changes. Can you clean it up and remove all the unrelated changes? Also it is possible to

Also take a look at this:

#616 (comment)

And this:

#616 (comment)

Also, it is possible to use the existing test fixtures versus adding new tables?

[Jack12816]

Also, it is possible to use the existing test fixtures versus adding new tables?

No, because there is no table which allows null-values on primary key values. The regular method is to just add the columns and on top a unique index combining all the relevant columns into a "primary key".

But it seems to include a lot of additional, unrelated changes. Can you clean it up and remove all the unrelated changes?

As already mentioned: Ah and sorry for the diff glitches, but the code base does not enforce any automatic linting and I'm used to not mix tabs/spaces and/or having trailing whitespaces (automatic fixes on my side). The touched files are just cleaned up by my editor automatically. If you really prefer to keep them as is - I have to redo my changes. But I'd prefer the boy scout rule :)

[cfis]

I can live with the formatting changes, but in a separate PR though.

[Jack12816]

About the referenced comments: I'm afraid Rails is doing wrong at this point, too. Or the objective is different from this gem. Until now I was able to use a composite primary key with null-able values as explained earlier, even if this is not a primary key from database data type perspective.

Unfortunately this is also the same for .delete_all/.updated_all queries:

ReferenceCode.unscoped.delete_all

results in:

-- given: (reference_type_id, reference_code) 
--        VALUES (null, 1), (1, 1)

DELETE FROM reference_codes
      WHERE (reference_codes.reference_type_id, reference_codes.reference_code)
            IN (
                SELECT reference_codes.reference_type_id,
                       reference_codes.reference_code
                  FROM reference_codes
              );

-- deletes just 1 row (second), the one without null value

instead of:

DELETE FROM reference_codes;

-- deletes 2/all rows

This also breaks the behaviour on null value rows for no good reason.

So the question is: what's the objective of this gem now? Allow and handle null values or not?

[cfis]

Sorry not following - are you referring to the changes in #621?

Handling null values would be great, but CPK can't break non-CPK tables. But I think that applies to the other PR, not this one?

[Jack12816]

I solved my upgrade issue by just adding an UUID primary key next to the unique index which served as CPK before, and just drop the CPK gem. Good enough for me.

I guess it was just a lucky accident that the 11.x versions supported our original use case. And when nobody ever faced the null-value issue, nevermind.