Return-Path: X-Original-To: apmail-hive-user-archive@www.apache.org Delivered-To: apmail-hive-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 113FF9DC7 for ; Tue, 5 Jun 2012 15:51:15 +0000 (UTC) Received: (qmail 3640 invoked by uid 500); 5 Jun 2012 15:51:13 -0000 Delivered-To: apmail-hive-user-archive@hive.apache.org Received: (qmail 3588 invoked by uid 500); 5 Jun 2012 15:51:13 -0000 Mailing-List: contact user-help@hive.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hive.apache.org Delivered-To: mailing list user@hive.apache.org Received: (qmail 3579 invoked by uid 99); 5 Jun 2012 15:51:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jun 2012 15:51:13 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of kulkarni.swarnim@gmail.com designates 209.85.212.48 as permitted sender) Received: from [209.85.212.48] (HELO mail-vb0-f48.google.com) (209.85.212.48) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jun 2012 15:51:07 +0000 Received: by vbjk17 with SMTP id k17so4199921vbj.35 for ; Tue, 05 Jun 2012 08:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=cl25gT+yuuYrUNndmPYj82Dpno+olwtkOafPovAqiH8=; b=PDJ/o/KTeeWf8vBrnnGimBkrJBgVGV6FKI7T2oZPuTbPu/q548kzEEz9QX7fmJlUC0 YwO74iQixHdHeaKYLUBEFQOWrBcFfLe2M5HLQ9bW614Joy/kyfY6onaf3fWjREFW6wjF k3QlkEjRQMeezWUPtqT7cvkWGxJgt6s6PW1fPzv2MhtHar/E3Ud8/30v06FFkyoH327C vIdo2IcHEQCSdhgmCf/KowMPTBsMPTEOeDAqolLVht0BvE1+dD4ZmY70/Zf5c1Jie1LH ZSoifPrqmws4u7bhio6fdB3yRZXJyDEIrZUE7Anb5FEzOfkso8bTAXnn5h+3eL0fDxSQ HX4g== Received: by 10.52.23.14 with SMTP id i14mr14891257vdf.47.1338911446800; Tue, 05 Jun 2012 08:50:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.191.198 with HTTP; Tue, 5 Jun 2012 08:50:26 -0700 (PDT) In-Reply-To: References: From: "kulkarni.swarnim@gmail.com" Date: Tue, 5 Jun 2012 10:50:26 -0500 Message-ID: Subject: Re: getStructFieldData method on StructObjectInspector To: user@hive.apache.org Content-Type: multipart/alternative; boundary=20cf307c9e542c19c804c1bb9d57 X-Virus-Checked: Checked by ClamAV on apache.org --20cf307c9e542c19c804c1bb9d57 Content-Type: text/plain; charset=ISO-8859-1 Thanks Edward for your reply on this. Would you mind giving a very small example on how a struct corresponds to a Map? I am having hard time understanding what the K/V pairs in the map would look like. Thanks again. On Tue, May 29, 2012 at 10:16 AM, Edward Capriolo wrote: > Returning custom writables will not work. In most cases the methods > return Object because the types can be many things that do not fall > under a single superclass other then object. like Integer,IntWritable, > Array, or Map. In your case, a struct corresponds to a > Map. > > On Tue, May 29, 2012 at 11:08 AM, kulkarni.swarnim@gmail.com > wrote: > > If someone can help understand this, I would really appreciate. > > > > On Fri, May 25, 2012 at 3:58 PM, kulkarni.swarnim@gmail.com > > wrote: > >> > >> I am trying to write a custom ObjectInspector extending the > >> StructObjectInspector and got a little confused about the use of the > >> getStructFieldData method on the inspector. Looking at the definition > of the > >> method: > >> > >> public Object getStructFieldData(Object data, StructField fieldRef); > >> > >> I understand that the use of this method is to retrieve the specific > given > >> field from the buffer. However, what I don't understand is what is it > >> expected to return. I looked around the tests and related code and > mostly > >> stuff returned was either a LazyPrimitive or a LazyNonPrimitive, but I > >> couldn't find anything that enforces this(specially given that the > return > >> type is a plain "Object")! Does this mean that I am free to return even > my > >> custom object as a return type of this method? If so, what is the > guarantee > >> that it will be interpreted correctly down the pipeline? > >> > >> Thanks, > >> -- > >> Swarnim > > > > > > > > > > -- > > Swarnim > -- Swarnim --20cf307c9e542c19c804c1bb9d57 Content-Type: text/html; charset=ISO-8859-1 Thanks Edward for your reply on this.

Would you mind giving a very small example on how a struct corresponds to a Map? I am having hard time understanding what the K/V pairs in the map would look like.

Thanks again.

On Tue, May 29, 2012 at 10:16 AM, Edward Capriolo <edlinuxguru@gmail.com> wrote:
Returning custom writables will not work. In most cases the methods
return Object because the types can be many things that do not fall
under a single superclass other then object. like Integer,IntWritable,
Array<IntWritable>, or Map. In your case, a struct corresponds to a
Map.

On Tue, May 29, 2012 at 11:08 AM, kulkarni.swarnim@gmail.com
<kulkarni.swarnim@gmail.com> wrote:
> If someone can help understand this, I would really appreciate.
>
> On Fri, May 25, 2012 at 3:58 PM, kulkarni.swarnim@gmail.com
> <kulkarni.swarnim@gmail.com> wrote:
>>
>> I am trying to write a custom ObjectInspector extending the
>> StructObjectInspector and got a little confused about the use of the
>> getStructFieldData method on the inspector. Looking at the definition of the
>> method:
>>
>> public Object getStructFieldData(Object data, StructField fieldRef);
>>
>> I understand that the use of this method is to retrieve the specific given
>> field from the buffer. However, what I don't understand is what is it
>> expected to return. I looked around the tests and related code and mostly
>> stuff returned was either a LazyPrimitive or a LazyNonPrimitive, but I
>> couldn't find anything that enforces this(specially given that the return
>> type is a plain "Object")! Does this mean that I am free to return even my
>> custom object as a return type of this method? If so, what is the guarantee
>> that it will be interpreted correctly down the pipeline?
>>
>> Thanks,
>> --
>> Swarnim
>
>
>
>
> --
> Swarnim



--
Swarnim
--20cf307c9e542c19c804c1bb9d57--