[
https://issues.apache.org/jira/browse/NIFI-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14378058#comment-14378058
]
Mark Payne commented on NIFI-461:
---------------------------------
[~bbende]: wow, nice!
I have no experience with Solr, personally, so I have a few suggestions that
may make no sense at all, given that info. But it is a really cool idea to
integrate with them. So if a suggestion doesn't make sense, then cool, no
problem, just let me know. Some of these comments are probably things that we
could document better in the developer guide, too.
For the Abstract class:
* SOLR_TYPE: this property doesn't really need a validator, since you are
setting explicit Allowable Values. It doesn't hurt to have it, but i generally
don't set them.
* createSolrServer() / getSolrServer() return a SolrClient, not a SolrServer.
Should these be renamed?
* No need for the "additionalOnScheduled" method. You can have many methods,
all annotated with @OnScheduled, and all of them will be called. Unless you
explicitly want to ensure that one specific method is called before the other -
but I don't think that's necessary here.
* Instead of Default Collection, I recommend just calling it "Collection" and
allowing the Expression Language to be used.
For GetSolr:
* Incoming FlowFile get() and route to success -> Should not pull FlowFile at
all. This way, the user can realize that the Processor doesn't expect this and
redirect the Connection. We have a ticket to allow a Processor to support an
annotation that prevents a Connection from even being connected to Source
processors like this: https://issues.apache.org/jira/browse/NIFI-20
* filterQuery.append(context.getProperty(DATE_FIELD).getValue())
.append(":{").append(lastEndDatedRef.get()).append(" TO ")
.append(currDate).append("]");
--> Do we really want to append { … ]
Is that a typo or is it correct? I.e., is it supposed to be an open curly
and close bracket? Just want to make sure.
PutSolrContentStream:
* "Content Stream URL" should be "Content Stream Path"? Or "Content Stream URL
Path"? It is not actually a URL but rather the "path" portion of a URL. Also,
should probably support expression language.
* Content-Type: Would recommend we support expression language.
* Recommend we use "success" relationship instead of "original" because the
FlowFile is not being modified.
* It might make sense instead of using "Request Parameters", which can be quite
complicated to read/write, to use user-defined properties. So instead of
setting this property to "k1=v1&k2=v2&k3=v3", the user can just add a property
named "k1" with a value "v1", etc. This is a little easier to read, and the
processor could easily URLEncode the parameters if it needs to, or handle them
however is appropriate.
Again, if some of these suggestions don't make sense, please excuse my
ignorance of Solr :)
> Add processors to interact with Apache Solr
> -------------------------------------------
>
> Key: NIFI-461
> URL: https://issues.apache.org/jira/browse/NIFI-461
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Core Framework
> Reporter: Bryan Bende
> Priority: Minor
>
> I'd like to see processors for interacting with Apache Solr.
> Solr has a variety of "update handlers" which allow posting data for
> indexing, and NiFi would be a great framework to provide the data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
