I am looking to simplify some. Here is the code I am looking at:

  private Mutation cloneMutation(Mutation m) throws IOException {
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    DataOutputStream dos = new DataOutputStream(baos);
    m.write(dos);
    dos.close();

    ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
    DataInputStream dis = new DataInputStream(bais);

    Mutation m = new Mutation();
    m.readFields(dis);
    return m;
  }

The readFields method in Mutation starts like this:

  @Override
  public void readFields(DataInput in) throws IOException {
  ...
  }

It seems harmless to have readFields return 'this' instead fo void.
Any objections?

On a slightly different note, it seems like readFields should actually
be a constructor. Because it's job is to set the row, data, value, and
entries. Just as the other constructors do. Any objections to
converting it to a constructor.

On Tue, Sep 11, 2012 at 9:31 AM, David Medinets <[EMAIL PROTECTED]>wrote:

> I am looking to simplify some. Here is the code I am looking at:
>
>   private Mutation cloneMutation(Mutation m) throws IOException {
>     ByteArrayOutputStream baos = new ByteArrayOutputStream();
>     DataOutputStream dos = new DataOutputStream(baos);
>     m.write(dos);
>     dos.close();
>
>     ByteArrayInputStream bais = new
> ByteArrayInputStream(baos.toByteArray());
>     DataInputStream dis = new DataInputStream(bais);
>
>     Mutation m = new Mutation();
>     m.readFields(dis);
>     return m;
>   }
>
> The readFields method in Mutation starts like this:
>
>   @Override
>   public void readFields(DataInput in) throws IOException {
>   ...
>   }
>
> It seems harmless to have readFields return 'this' instead fo void.
> Any objections?
>
> On a slightly different note, it seems like readFields should actually
> be a constructor. Because it's job is to set the row, data, value, and
> entries. Just as the other constructors do. Any objections to
> converting it to a constructor.
>

That readFields method is inherited from Writable, so you can't change it.
When I made IteratorSetting extend Writable recently, I thought it would be
nice to have a constructor IteratorSetting(DataInput din) that calls
readFields, so I added it.  I wouldn't be opposed to adding such a
constructor to Mutation.

Billie

I want to add this constructor:

  public Mutation(DataInput in) {
    try {
readFields(in);
} catch (IOException e) {
throw new RuntimeException(e);
}
  }

And use it like this:

  private Mutation cloneMutation(Mutation m) throws IOException {
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    DataOutputStream dos = new DataOutputStream(baos);
    m.write(dos);
    dos.close();

    ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
    DataInputStream dis = new DataInputStream(bais);

    return new Mutation(dis);
  }

Does anything look wrong?

Should theose InputStreams be closed inside a finally clause?
On Tue, Sep 11, 2012 at 9:41 AM, Billie Rinaldi <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 11, 2012 at 9:31 AM, David Medinets <[EMAIL PROTECTED]>wrote:
>
>> I am looking to simplify some. Here is the code I am looking at:
>>
>>   private Mutation cloneMutation(Mutation m) throws IOException {
>>     ByteArrayOutputStream baos = new ByteArrayOutputStream();
>>     DataOutputStream dos = new DataOutputStream(baos);
>>     m.write(dos);
>>     dos.close();
>>
>>     ByteArrayInputStream bais = new
>> ByteArrayInputStream(baos.toByteArray());
>>     DataInputStream dis = new DataInputStream(bais);
>>
>>     Mutation m = new Mutation();
>>     m.readFields(dis);
>>     return m;
>>   }
>>
>> The readFields method in Mutation starts like this:
>>
>>   @Override
>>   public void readFields(DataInput in) throws IOException {
>>   ...
>>   }
>>
>> It seems harmless to have readFields return 'this' instead fo void.
>> Any objections?
>>
>> On a slightly different note, it seems like readFields should actually
>> be a constructor. Because it's job is to set the row, data, value, and
>> entries. Just as the other constructors do. Any objections to
>> converting it to a constructor.
>>
>
> That readFields method is inherited from Writable, so you can't change it.
> When I made IteratorSetting extend Writable recently, I thought it would be
> nice to have a constructor IteratorSetting(DataInput din) that calls
> readFields, so I added it.  I wouldn't be opposed to adding such a
> constructor to Mutation.
>
> Billie

David,

Could you use org.apache.hadoop.io.WritableUtils.clone() or
org.apache.hadoop.io.WritableUtils.cloneInto()?

Keith

On Tue, Sep 11, 2012 at 11:38 AM, David Medinets
<[EMAIL PROTECTED]> wrote:
> I want to add this constructor:
>
>   public Mutation(DataInput in) {
>     try {
>                 readFields(in);
>         } catch (IOException e) {
>                 throw new RuntimeException(e);
>         }
>   }
>
> And use it like this:
>
>   private Mutation cloneMutation(Mutation m) throws IOException {
>     ByteArrayOutputStream baos = new ByteArrayOutputStream();
>     DataOutputStream dos = new DataOutputStream(baos);
>     m.write(dos);
>     dos.close();
>
>     ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
>     DataInputStream dis = new DataInputStream(bais);
>
>     return new Mutation(dis);
>   }
>
> Does anything look wrong?
>
> Should theose InputStreams be closed inside a finally clause?
>
>
> On Tue, Sep 11, 2012 at 9:41 AM, Billie Rinaldi <[EMAIL PROTECTED]> wrote:
>> On Tue, Sep 11, 2012 at 9:31 AM, David Medinets <[EMAIL PROTECTED]>wrote:
>>
>>> I am looking to simplify some. Here is the code I am looking at:
>>>
>>>   private Mutation cloneMutation(Mutation m) throws IOException {
>>>     ByteArrayOutputStream baos = new ByteArrayOutputStream();
>>>     DataOutputStream dos = new DataOutputStream(baos);
>>>     m.write(dos);
>>>     dos.close();
>>>
>>>     ByteArrayInputStream bais = new
>>> ByteArrayInputStream(baos.toByteArray());
>>>     DataInputStream dis = new DataInputStream(bais);
>>>
>>>     Mutation m = new Mutation();
>>>     m.readFields(dis);
>>>     return m;
>>>   }
>>>
>>> The readFields method in Mutation starts like this:
>>>
>>>   @Override
>>>   public void readFields(DataInput in) throws IOException {
>>>   ...
>>>   }
>>>
>>> It seems harmless to have readFields return 'this' instead fo void.
>>> Any objections?
>>>
>>> On a slightly different note, it seems like readFields should actually
>>> be a constructor. Because it's job is to set the row, data, value, and
>>> entries. Just as the other constructors do. Any objections to
>>> converting it to a constructor.
>>>
>>
>> That readFields method is inherited from Writable, so you can't change it.
>> When I made IteratorSetting extend Writable recently, I thought it would be
>> nice to have a constructor IteratorSetting(DataInput din) that calls
>> readFields, so I added it.  I wouldn't be opposed to adding such a
>> constructor to Mutation.
>>
>> Billie