Right now, the fields of the documents that the NoSql appender creates are fixed, unless you use a MapMessage and a MessageLayout. In this case you get the fields from the MapMessage but none of the default fields.
If you do this (Kotlin code in this example, but Java would have the same problem):
logger.info(MapMessage(mapOf("aa" to "11", "bb" to "22")))
I have been doing some analysis and I believe that this functionality would be very difficult to achieve with the provided extension points, as the code that creates the document layout can't be swapped from configuration.
Then it would be easy to create a custom Message or a Layout that can control the message field and set it to something more interesting than repeating the custom properties (not part of this request). StructuredDataMessage, for instance, already has a message property that can be used via a custom layout.
I propose creating a configuration option that would enable this behavior.
I have been looking at the code and, apart from creating the configuration option, only a minor change would be required here:
if (serializable instanceof MapMessage) {
// Add these three lines
if (newOption){
setFields(event, entity);
}
setFields((MapMessage<?, ?>) serializable, entity);
} else {
setFields(event, entity);
}
Another option (maybe more flexible) would be to move all the code that sets the document properties from the event (writeInternal and setFields methods from NoSqlDatabaseManager) to a new class that can be swapped via configuration. Something in the lines of a NoSqlObjectLayout that would be conceptually similar to Layouts but that outputs (or sets fields to) a NoSql document instead of a String.
Right now, the fields of the documents that the NoSql appender creates are fixed, unless you use a MapMessage and a MessageLayout. In this case you get the fields from the MapMessage but none of the default fields.
If you do this (Kotlin code in this example, but Java would have the same problem):
You can either get this:
Or this:
I want this (order of the fields is unimportant):
I have been doing some analysis and I believe that this functionality would be very difficult to achieve with the provided extension points, as the code that creates the document layout can't be swapped from configuration.
Then it would be easy to create a custom Message or a Layout that can control the message field and set it to something more interesting than repeating the custom properties (not part of this request). StructuredDataMessage, for instance, already has a message property that can be used via a custom layout.
I propose creating a configuration option that would enable this behavior.
I have been looking at the code and, apart from creating the configuration option, only a minor change would be required here:
Another option (maybe more flexible) would be to move all the code that sets the document properties from the event (
writeInternal
andsetFields
methods fromNoSqlDatabaseManager
) to a new class that can be swapped via configuration. Something in the lines of aNoSqlObjectLayout
that would be conceptually similar to Layouts but that outputs (or sets fields to) a NoSql document instead of aString
.