[
https://issues.apache.org/jira/browse/NIFI-5059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504719#comment-16504719
]
ASF GitHub Bot commented on NIFI-5059:
--------------------------------------
Github user bbende commented on the issue:
https://github.com/apache/nifi/pull/2619
I haven't gone too deep looking at this, but if the goal is to have a
re-usable way to infer a schema from JSON across various NoSQL components, have
we considered just putting some utility code in a JAR somewhere under
nifi-nar-bundles/nifi-extension-utils rather than trying to hook into the
SchemaAccessStrategy/SchemaRegistryService?
I'm just on the fence about whether the schema access stuff makes sense
here since that was designed for the readers/writers, and this is really coming
from a different angle of already having some Map object in memory.
> MongoDBLookupService should be able to determine a schema or have one provided
> ------------------------------------------------------------------------------
>
> Key: NIFI-5059
> URL: https://issues.apache.org/jira/browse/NIFI-5059
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Mike Thomsen
> Assignee: Mike Thomsen
> Priority: Major
>
> MongoDBLookupService should have two schema handling modes:
> # Where a schema is provided as a configuration parameter to be applied to
> the Record object generated from the result document.
> # A schema will be generated by examining the result object and building one
> that roughly translates from BSON into the Record API.
> In both cases, the schema will be applied to the Mongo result Document object
> that is returned if one comes back.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
