Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Import/Export creates field with empty string rather than null #3880

Open
pedro-psb opened this issue Feb 13, 2025 · 3 comments
Open

Import/Export creates field with empty string rather than null #3880

pedro-psb opened this issue Feb 13, 2025 · 3 comments
Labels

Comments

@pedro-psb
Copy link
Member

pedro-psb commented Feb 13, 2025

Version

Tested on pulp_rpm 3.28, core 3.70. Probably applies to lower versions.

Describe the bug

GIVEN a dataset exported from an rpm repository
WHEN importing that with the option to create repositories equal True
THEN the created repositories will contain optional fields [0] as empty strings rather than null (diverges from normal behavior)

[0] checksum_type and the deprecated [metadata_checksum_type, package_checksum_type, compression_type]

To Reproduce

Run test test_create_missing_repos, breakpoint after step 6 and check repositories in the database. There should be two repositories with empty string, rather than null.

On a database GUI (AnataresSQL here) the column shows more clearly what is null or not.

pulp=> select repository_ptr_id, checksum_type from rpm_rpmrepository where checksum_type is not null;
          repository_ptr_id           | checksum_type
--------------------------------------+---------------
 0194f5f8-0cf3-7018-a331-de7feab46a2e |
 0194f5f8-0d13-724c-be0e-41ff15eea629 |
(2 rows)

Alternatively, remove this workaround that casts empty string to null and watch this same test fail (because bindings validates that when creating a list/show response).

Expected behavior

These fields should have null values instead of empty string, as it happens when creating repos via the API.

Additional context

That was found during the core 3.70 compat changes, responding to strict validation from the bindings.

https://issues.redhat.com/browse/PULP-341

@dralley
Copy link
Contributor

dralley commented Mar 19, 2025

I believe this is down to default django-import-export behavior that changed in a newer version.

https://django-import-export.readthedocs.io/en/latest/release_notes.html#export-format

Hopefully updating django-import-export fixes these issues.

@dralley
Copy link
Contributor

dralley commented Mar 19, 2025

Or not. I got that backwards, they didn't change the behavior. Either way though this is apparently "intended" django-import-export behavior for some reason.

@dralley dralley removed their assignment Mar 19, 2025
@dralley
Copy link
Contributor

dralley commented Mar 19, 2025

We realistically cannot touch the version of django-import-export until a breaking change release. And we have to be very careful about changing any core behavior also. We need to do a whole audit around domains since it isn't domain aware.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants