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

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


+
Nick Dimiduk 2013-03-13, 16:42
+
David Koch 2013-03-14, 16:51
+
Michel Segel 2013-03-15, 12:25
+
Nick Dimiduk 2013-03-15, 17:06
+
Michel Segel 2013-03-15, 22:35
+
Nick Dimiduk 2013-03-19, 20:34
+
Nick Dimiduk 2013-03-15, 17:11
+
James Taylor 2013-03-15, 17:55
+
Nick Dimiduk 2013-03-15, 17:57
+
lars hofhansl 2013-03-16, 05:45
+
Michel Segel 2013-03-16, 12:18
+
Michel Segel 2013-03-16, 12:26
+
Andrew Purtell 2013-03-16, 12:59
+
Michael Segel 2013-03-17, 16:13
+
Andrew Purtell 2013-03-17, 17:12
+
Amit Sela 2013-03-17, 17:32
+
Michel Segel 2013-03-18, 12:02
+
Doug Meil 2013-03-18, 19:16
+
Michael Segel 2013-03-19, 00:42
+
Mohamed Ibrahim 2013-03-17, 17:24
+
ramkrishna vasudevan 2013-03-18, 03:01
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.
+
Nick Dimiduk 2013-03-19, 20:35
+
Jonathan Hsieh 2013-03-18, 23:54
+
Michael Segel 2013-03-19, 00:31
+
Nick Dimiduk 2013-03-19, 20:38
+
Nick Dimiduk 2013-03-19, 20:30