Splitting seralizers into read and write ones

[fao89]

https://pulp.plan.io/issues/6775
closes #6775

Please be sure you have read our documentation on creating PRs:
https://docs.pulpproject.org/contributing/pull-request-walkthrough.html

[pulpbot]

Warning: Issue #6346 is not at NEW/ASSIGNED/POST.

[mdellweg]

I think that comparison is too risky. Can you compare the keys() for equality?

[mdellweg]

Suggested change

	contain_write_fields = len(serializer.fields) > len(read_fields)
	if self.method.lower() == "get" or not contain_write_fields:
	serializer.fields = read_fields
	return serializer
	contain_write_only_fields = len(serializer.fields) > len(read_fields)
	if self.method.lower() == "get" or not contain_write_only_fields:
	serializer.fields = read_fields
	return serializer

Also: are serializer.fields and read_fields not exactly the same in this case?

[mdellweg]

I belive we agreed to perform this transformation on the read-serializer and not the write-serializer.

[dkliban]

That's right ... we want the write serializer to keep the original name and the read serializer to change to OriginalNameRead.

The motivation for this outlined here: https://www.redhat.com/archives/pulp-dev/2020-April/msg00101.html

[mdellweg]

That use of write_only should be preserved. As the database for content does not have that field.

[fao89]

Many plugins are counting with a response with relative_path, keeping it as write_only would break them:
https://travis-ci.com/github/pulp/pulpcore/jobs/338483661#L1866
https://github.com/pulp/pulp_deb/blob/7c90e1dea8583c9bb838ce77014243adaacceee8/pulp_deb/tests/functional/api/test_crud_content_unit.py#L77

[mdellweg]

That's interesting, because in those cases, the write_onlyness should be deactivated dynamically in the __init__ of the serializer. Are you assigning the model attribute on the ReadOnly serializer you are creating on the fly?

[fao89]

I'll put a rpdb to see why it is ignoring the __init__

[fao89]

with ReadOnly mixin I was getting the fields from the original serializer class, so the __init__ was not triggered. So instead of creating a new serializer class from the mixin, I'm doing it by modifying the serializer object.

[mdellweg]

I left a question, how to maybe simplify the pr. It should not be blocking this PR.

Thanks for adressing all my concerns.

[mdellweg]

So this new class is there to change the ref_name. Anyway we can get away without crating that transient class by just setting that ref_name on the instance original_serializer (like we do with the fields two lines down)?

[fao89]

I tried, but it changes the original serialize, and I ended up with SerializerNameReadReadRead

[mdellweg]

Then just ignore this one.

[dkliban]

I tested this by creating a PythonPythonPackageContent. Worked great!