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

Switch to Threaded View
Avro >> mail # user >> Issue with default namespace


Copy link to this message
-
Re: Issue with default namespace
Graham,

This does indeed look like a bug that affects printing of both enum
and fixed schemas that have a namespace when nested within a record
with no namespace.  The fix seems as simple as the following:

--- Schema.java (revision 1522738)
+++ Schema.java (working copy)
@@ -458,8 +458,6 @@
       if (space != null) {
         if (!space.equals(names.space()))
           gen.writeStringField("namespace", space);
-        if (names.space() == null)                // default namespace
-          names.space(space);
       } else if (names.space() != null) {         // null within non-null
         gen.writeStringField("namespace", "");
       }

Please file an issue in Jira.

Thanks,

Doug

On Mon, Sep 16, 2013 at 6:58 PM, graham sanderson <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Here is a condensed example of a problem I just came across
>
>     @Test
>     void testNamespaceBleed() throws Exception {
>         Schema schema = SchemaBuilder.record("test").fields()
>                 .name("field1").type().enumeration("Bar").namespace("com.foo").symbols("x").noDefault()
>                 .name("field2").type().record("Humbug").namespace("com.foo").fields().endRecord().noDefault()
>                 .endRecord();
>         String schemaString = schema.toString(true);
>         Schema schema2 = new Schema.Parser().parse(schemaString);
>         Assert.assertEquals(schema, schema2); // one would hope this were true
>     }
>
> Basically the use case (which may not be very common) is with the first (namespaced) schema in a record without a namespace being an enum. Because the serialization of the enum schema does not save and restore the namespace, it becomes the default namespace (for serialization) of other fields that follow in the same record (so field2 is written without a namespace since it is in the default namespace, but when the schema is deserialized the same bug does not occur and so it appears a "Humbug" rather than "com.foo.Humbug")
>
> Note, the following (and of course most others) all work
>
>     @Test
>     void testNoNamespaceBleed() throws Exception {
>         // works because the enclosing record has a namespace
>         Schema schema = SchemaBuilder.record("test").namespace("com.foo").fields()
>                 .name("field1").type().enumeration("Bar").namespace("com.foo").symbols("x").noDefault()
>                 .name("field2").type().record("Humbug").namespace("com.foo").fields().endRecord().noDefault()
>                 .endRecord();
>         String schemaString = schema.toString(true);
>         Schema schema2 = new Schema.Parser().parse(schemaString);
>         Assert.assertEquals(schema,schema2);
>
>         // works because the enclosing record has a namespace (even though different)
>         schema = SchemaBuilder.record("test").namespace("com.bar").fields()
>                 .name("field1").type().enumeration("Bar").namespace("com.foo").symbols("x").noDefault()
>                 .name("field2").type().record("Humbug").namespace("com.foo").fields().endRecord().noDefault()
>                 .endRecord();
>         schemaString = schema.toString(true);
>         schema2 = new Schema.Parser().parse(schemaString);
>         Assert.assertEquals(schema,schema2);
>
>         // works because the enum and the field are in different namespaces
>         schema = SchemaBuilder.record("test").fields()
>                 .name("field1").type().enumeration("Bar").namespace("com.bar").symbols("x").noDefault()
>                 .name("field2").type().record("Humbug").namespace("com.foo").fields().endRecord().noDefault()
>                 .endRecord();
>         schemaString = schema.toString(true);
>         schema2 = new Schema.Parser().parse(schemaString);
>         Assert.assertEquals(schema,schema2);
>     }
>
> I can open an issue, I just wanted to check with the list first that this is not intended behavior (which seems unlikely) - I assume this issue affects fixed schemas too, but I haven't checked
>
> Thanks,
>