You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by David Medinets <da...@gmail.com> on 2012/09/11 15:31:58 UTC
Can Mutation.readFields return Mutation instead fo void?
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.
Re: Can Mutation.readFields return Mutation instead fo void?
Posted by Keith Turner <ke...@deenlo.com>.
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
<da...@gmail.com> 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 <bi...@apache.org> wrote:
>> On Tue, Sep 11, 2012 at 9:31 AM, David Medinets <da...@gmail.com>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
Re: Can Mutation.readFields return Mutation instead fo void?
Posted by David Medinets <da...@gmail.com>.
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 <bi...@apache.org> wrote:
> On Tue, Sep 11, 2012 at 9:31 AM, David Medinets <da...@gmail.com>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
Re: Can Mutation.readFields return Mutation instead fo void?
Posted by Billie Rinaldi <bi...@apache.org>.
On Tue, Sep 11, 2012 at 9:31 AM, David Medinets <da...@gmail.com>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