Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Flume, mail # dev - Questions about Morphline Solr Sink structure


Copy link to this message
-
Re: Questions about Morphline Solr Sink structure
Otis Gospodnetic 2013-11-12, 06:01
Hi,

But is it really about unpleasant names or about incorrect/misleading names?
If I were a developer and came across a class named MorphlineSolrSink
I'd never think I could use it to pump events into anything other than
Solr.  And if I read the docs that said otherwise I'd be confused and
would likely come to the mailing list for help (like I did, I guess).

Why can't the existing code be @deprecated?  Wouldn't that solve
backwards compatibility issue over the next 2 releases?

Thanks,
Otis
--
Performance Monitoring * Log Analytics * Search Analytics
Solr & Elasticsearch Support * http://sematext.com/
On Tue, Nov 12, 2013 at 12:30 AM, Wolfgang Hoschek
<[EMAIL PROTECTED]> wrote:
> Breaking backwards compat isn't an option for enterprise customers, especially if the only gain is making a bunch of names a little more pleasant.
>
> Wolfgang.
>
> On Nov 11, 2013, at 8:56 PM, Otis Gospodnetic wrote:
>
>> Hi,
>>
>> Hm, I don't get something here.  The class name is misleading/wrong,
>> no?  Why not go through the usual deprecation steps to avoid breaking
>> anything during the next release and then remove the
>> misnamed/misplaced classes completely?
>>
>> Also, I don't know enough about this code to understand fully why any
>> code here would need to ship without (unit) tests...
>>
>> While people could use MorphlineSolrSink even if they are not using it
>> with Solr, wouldn't that be a little.... messy? :)
>>
>> Thanks,
>> Otis
>> --
>> Performance Monitoring * Log Analytics * Search Analytics
>> Solr & Elasticsearch Support * http://sematext.com/
>>
>>
>> On Mon, Nov 11, 2013 at 8:25 PM, Roshan Naik <[EMAIL PROTECTED]> wrote:
>>> imho...would be nice if the code changes were done... but renaming it in
>>> the user guide (without changing FQCNs) can be done regardless. and perhaps
>>> more impt from a user perspective..
>>>
>>>
>>> On Mon, Nov 11, 2013 at 4:04 PM, Wolfgang Hoschek <[EMAIL PROTECTED]>wrote:
>>>
>>>> Yep, the names are a bit misleading now that so much has been generalized,
>>>> but whatever we do, breaking backwards compat isn't an option. Shipping a
>>>> sink without tests doesn't seem compelling to me either.
>>>>
>>>> Taste in names aside, as far as I can see you could use this sink for ES
>>>> today without any issues.
>>>>
>>>> Wolfgang.
>>>>
>>>> On Nov 11, 2013, at 4:00 PM, Hari Shreedharan wrote:
>>>>
>>>>> Hi Otis,
>>>>>
>>>>> I don’t mind doing any of that - but the problem is that such a change
>>>> could impact backward compatibility - so we’d need to keep the stubs around
>>>> even though the actual functionality might be elsewhere.
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Hari
>>>>>
>>>>>
>>>>> On Monday, November 11, 2013 at 3:54 PM, Otis Gospodnetic wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Thanks for the info, everyone.
>>>>>> Yes, I noticed after my email that Blob* classes were in the process
>>>>>> of being moved.
>>>>>> Here is what I feel should really be done:
>>>>>>
>>>>>> * get rid of ....solr.morphline package and move the code to
>>>>>> ...morphpline package
>>>>>> * get rid of any Solr-specific code (I guess just in the tests
>>>>>> Wolfgang mentioned)
>>>>>> * rename the sink to MorphlineSink
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Re loadElasticSearch() - yes, I see Wolfgang saw I opened an issue for
>>>>>> that in CDK.
>>>>>>
>>>>>> Thanks,
>>>>>> Otis
>>>>>> --
>>>>>> Performance Monitoring * Log Analytics * Search Analytics
>>>>>> Solr & Elasticsearch Support * http://sematext.com/
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 11, 2013 at 4:34 PM, Roshan Naik <[EMAIL PROTECTED](mailto:
>>>> [EMAIL PROTECTED])> wrote:
>>>>>>> We should consider rename the Morphline Solr Sink to Morphline sink in
>>>> the
>>>>>>> docs to avoid any possibility of misleading end users.
>>>>>>>
>>>>>>> --
>>>>>>> CONFIDENTIALITY NOTICE
>>>>>>> NOTICE: This message is intended for the use of the individual or
>>>> entity to
>>>>>>> which it is addressed and may contain information that is confidential,
>>>