[
https://issues.apache.org/jira/browse/SOLR-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020207#comment-14020207
]
Mikhail Khludnev edited comment on SOLR-4799 at 6/6/14 7:26 PM:
----------------------------------------------------------------
Despite of many things described above, I *agree* with [~jdyer]. Until we see
real demand for this feature, there is no need to pitch it. This "plugin" is
really easy to check as a separate drop-in, but you see how many users tried to
check it ... _no one_.
I understand what the morphlines is, after all. It's a pretty cool lightweight
transformation pipeline. but:
- it doesn't have jdbc input so far (i don't think it's hard to implement it)
- a pipeline implies a single chain of transformation, I don't see how to
naturally join two streams of records.
Regarding Flume I'm still concerned about its' minimum footprint.
fwiw here is the Kettle's approach to do the subj
http://wiki.pentaho.com/display/EAI/Merge+Join
was (Author: mkhludnev):
Despite of many things described above, I *agree* with [~jdyer]. Until we see
real demand for this feature, there is no need to pitch it. This "plugin" is
really easy to check as a separate drop-in, but you see how many users tried to
check it ... _no one_.
I understand what the morphlines is, after all. It's a pretty cool lightweight
transformation pipeline. but:
- it doesn't have jdbc input so far (i don't think it's hard to implement it)
- a pipeline implies a single chain of transformation, I don't see how to
naturally join two streams of records.
Regarding Flume I'm still concerned about its' minimum footprint.
> SQLEntityProcessor for zipper join
> ----------------------------------
>
> Key: SOLR-4799
> URL: https://issues.apache.org/jira/browse/SOLR-4799
> Project: Solr
> Issue Type: New Feature
> Components: contrib - DataImportHandler
> Reporter: Mikhail Khludnev
> Priority: Minor
> Labels: dih
> Attachments: SOLR-4799.patch
>
>
> DIH is mostly considered as a playground tool, and real usages end up with
> SolrJ. I want to contribute few improvements target DIH performance.
> This one provides performant approach for joining SQL Entities with miserable
> memory at contrast to
> http://wiki.apache.org/solr/DataImportHandler#CachedSqlEntityProcessor
> The idea is:
> * parent table is explicitly ordered by it’s PK in SQL
> * children table is explicitly ordered by parent_id FK in SQL
> * children entity processor joins ordered resultsets by ‘zipper’ algorithm.
> Do you think it’s worth to contribute it into DIH?
> cc: [~goksron] [~jdyer]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
