Patching for Issue 143 #29
Conversation
|
Can one of the admins verify this patch? |
|
It looks like @lukemao hasn't signed our Contributor License Agreement, yet. Appreciation of efforts, clabot |
There was a problem hiding this comment.
Forcibly overriding this seems to be counter to the goal of this constructor, which is to allow the user to get control over the exact settings of the ObjectMapper. Is there any reason this needs to be overridden here? If the caller chose to leave FAIL_ON_READING_DUP_TREE_KEY off, is there any reason not to respect that?
This might require adjustments to kafka-rest to address the issue that triggered this PR, but keep in mind this class is used across a few projects and some might not need to be as restrictive and might prefer being a bit more liberal with the input they accept.
There was a problem hiding this comment.
Sorry I was thinking having a single key per record to be produced is the requirement, as defined in the API reference page. Key should be uniquely identify a record. However, I think other REST function may also use this to parse their request, which may allow duplicated meta-data. I will change it back.
|
Just made another commit. Also changed the |
|
Can we provide a test that this actually behaves as expected? I'm not sure, but maybe it could fit into |
3 participants
Based on requirements specified in KAFKA Rest API (http://docs.confluent.io/1.0.1/kafka-rest/docs/api.html#consumers):
Request JSON Array of Objects:
records– A list of records to produce to the topic.records[i].key (object)– The message key, formatted according to the embedded format, or null to omit a key (optional)records[i].value (object)– The message value, formatted according to the embedded formatrecords[i].partition (int)– Partition to store the message in (optional)We can not provide duplicated keys when producing messages.
I updated the
rest-utilsto restrict number of key to be provided in message producing.