[
https://issues.apache.org/jira/browse/PIG-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972615#action_12972615
]
Alan Gates commented on PIG-1277:
---------------------------------
Comments:
# I'm not sure the null handling in NullableBytesWritable.getValueAsPigType is
the same. Previously it would check specifically if the value had been marked
as null. Now it looks like if there isn't an entry in the first slot of the
tuple (which I think would be what would happen if it were null) it will throw
an exception. I think you want to return the isNull check, and make sure the
constructors properly set that value.
# I don't understand the change in LOUnion.
> Pig should give error message when cogroup on tuple keys of different inner
> type
> --------------------------------------------------------------------------------
>
> Key: PIG-1277
> URL: https://issues.apache.org/jira/browse/PIG-1277
> Project: Pig
> Issue Type: Bug
> Components: impl
> Affects Versions: 0.6.0
> Reporter: Daniel Dai
> Assignee: Alan Gates
> Fix For: 0.9.0
>
> Attachments: PIG-1277-1.patch
>
>
> When we cogroup on a tuple, if the inner type of tuple does not match, we
> treat them as different keys. This is confusing. It is desirable to give
> error/warnings when it happens.
> Here is one example:
> UDF:
> {code}
> public class MapGenerate extends EvalFunc<Map> {
> @Override
> public Map exec(Tuple input) throws IOException {
> // TODO Auto-generated method stub
> Map m = new HashMap();
> m.put("key", new Integer(input.size()));
> return m;
> }
>
> @Override
> public Schema outputSchema(Schema input) {
> return new Schema(new Schema.FieldSchema(null, DataType.MAP));
> }
> }
> {code}
> Pig script:
> {code}
> a = load '1.txt' as (a0);
> b = foreach a generate a0, MapGenerate(*) as m:map[];
> c = foreach b generate a0, m#'key' as key;
> d = load '2.txt' as (c0, c1);
> e = cogroup c by (a0, key), d by (c0, c1);
> dump e;
> {code}
> 1.txt
> {code}
> 1
> {code}
> 2.txt
> {code}
> 1 1
> {code}
> User expected result (which is not right):
> {code}
> ((1,1),{(1,1)},{(1,1)})
> {code}
> Real result:
> {code}
> ((1,1),{(1,1)},{})
> ((1,1),{},{(1,1)})
> {code}
> We shall give user the message that we can not merge the key due to the type
> mismatch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
