Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> HBase type support


Copy link to this message
-
Re: HBase type support
If we look at TSDB, Kiji, Asynch HBase, it looks like extensions to HBase already exist.

I haven't looked at Salesforce,com's SQL interface, but I suspect that they too have some sort of framework where they have to enforce typing.
Sent from a remote device. Please excuse any typos...

Mike Segel

On Mar 17, 2013, at 10:01 PM, ramkrishna vasudevan <[EMAIL PROTECTED]> wrote:

> HBase shipping a generic framework for different interfaces is needed for
> ease of use for the users.  +1 on the idea.
> Getting out the correct result for float values, positive and negative
> integers had to be taken care by the users or by using some wrappers.
>
> This will help to solve that problem to a great extent.
>
> Regards
> Ram
>
> On Sun, Mar 17, 2013 at 10:54 PM, Mohamed Ibrahim <[EMAIL PROTECTED]>wrote:
>
>> I'm not a lawyer, but I think we're ok as long as it's in source code as
>> that is protected under freedom of speech in the US. See here (
>> http://en.wikipedia.org/wiki/Cryptography ) under Export Control, the part
>> related to Bernstein v. United States . I don't know about binaries like
>> deb, but I can tell that we download binaries for browsers every day and
>> they use encryption in lots of places. I believe if there's any real issues
>> it would have surfaced up by now.
>>
>> As far as types in HBase, I think it is an excellent idea. I would suggest
>> to enable us to add a custom type, just like we can add our custom filters.
>> Some types that I had to code myself include CSV. There can be other custom
>> types that I need in the future, may be json, so the ability to add a
>> custom type might be a good feature.
>>
>> Thanks,
>> Mohamed
>>
>>
>> On Sun, Mar 17, 2013 at 1:12 PM, Andrew Purtell <[EMAIL PROTECTED]>
>> wrote:
>>
>>>> This then leads to another question... suppose Apache does add
>> encryption
>>> to Hadoop. While the Apache organization does have the proper paperwork
>> in
>>> place, what then happens to Cloudera, Hortonworks, EMC, IBM, Intel, etc ?
>>>
>>> Well I can't put that question aside since you've brought it up now
>>> twice and encryption feature candidates for Apache Hadoop and Apache
>> HBase
>>> are something I have been working on. Its a valid question but since as
>> you
>>> admit you don't know what you are talking about, perhaps stating
>> uninformed
>>> opinions can be avoided. Only the latter is what I object to. I think the
>>> short answer is as an Apache contributor I'm concerned about the Apache
>>> product. Downstream repackagers can take whatever action needed including
>>> changes, since it is open source, or feedback about it representing a
>>> hardship. At this point I have heard nothing like that. I work for Intel
>>> and can say we are good with it.
>>>
>>> On Sunday, March 17, 2013, Michael Segel wrote:
>>>
>>>> Its not a question of FUD, but that certain types of
>>> encryption/decryption
>>>> code falls under the munitions act.
>>>> See: http://www.fas.org/irp/offdocs/eo_crypt_9611_memo.htm
>>>>
>>>> Having said that, there is this:
>>>> http://www.bis.doc.gov/encryption/encfaqs6_17_02.html
>>>>
>>>> In short, I don't as a habit export/import encryption technology so I
>> am
>>>> not up to speed on the current state of the laws.
>>>> Which is why I have to question the current state of the US encryption
>>>> laws.
>>>>
>>>> This then leads to another question... suppose Apache does add
>> encryption
>>>> to Hadoop. While the Apache organization does have the proper paperwork
>>> in
>>>> place, what then happens to Cloudera, Hortonworks, EMC, IBM, Intel,
>> etc ?
>>>>
>>>> But lets put that question aside.
>>>>
>>>> The point I was trying to make was that the core Sun JVM does support
>> MD5
>>>> and SHA-1 out of the box, so that anyone running Hadoop and using the
>>>> 1.6_xx or the 1.7_xx versions of the JVM will have these packages.
>>>>
>>>> Adding hooks that use these classes are a no brainer.  However, beyond
>>>> this... you tell me.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB