Back when I wrote the initial CassandraAppender implementation, I found the existing NoSQL interfaces to be too restrictive. I found a similar problem long ago when I was experimenting with a DynamoDB appender. Most NoSQL APIs I've used tend to accept a generic Map for documents/records, and it was only the Mongo API that had its own thing going on.
With that in mind, I'd support breaking that API and redoing it entirely so it's not as specific to Mongo/Couch. I think I still have a backlog item about implementing a DynamoDB appender, and I'd also like to see something similar eventually for Elasticsearch (which I've been working with extensively lately). On 21 January 2018 at 23:47, Gary Gregory <[email protected]> wrote: > Hi All, > > The interface org.apache.logging.log4j.core.appender.nosql.NoSqlObject<W> > requires arrays in two methods: > > set(String, NoSqlObject<BasicDBObject>[]) > set(String, Object[]) > > For some providers like the new MongoDB driver 3.x provider I am working on > this causes double work. First the log4j NoSQL guts converts a list into an > array > in org.apache.logging.log4j.core.appender.nosql.NoSqlDatabaseManager. > setFields(LogEvent, > NoSqlObject<W>): > > entity.set("contextStack", contextStack.asList().toArray()); > > Then, the new NoSqlObject impl I have converts that array back into a list > to pass to Mongo. > > If I wanted to add List versions of the two array APIs in NoSqlObject, > should I: > > - Just add-em and adjust all providers. > - Create a NoSqlObject2 sub-interface > > Thoughts? > > Gary > -- Matt Sicker <[email protected]>
