Doug: thanks a lot for the fast fix.
it works now, but there is a minor issue, I'm not sure if this is the desired behavior: in the client schema, I set the string field "extra_field" with a default value of null, on the server side, the server probably tries to use that default value, and gave the following error: Tests in error: testClientDiffReturnType(org.apache.avro.TestSimpleClient): Non-string default value for string: null Tests run: 2, Failures: 0, Errors: 1, Skipped: 0 is a NULL default value for string valid? if so, then it's all fine Thanks Yang On Tue, May 31, 2011 at 3:17 AM, Doug Cutting <[email protected]> wrote: > This is a bug. I've filed an issue and attached a patch that fixes it: > > https://issues.apache.org/jira/browse/AVRO-832 > > Please tell me if this fixes things for you. > > Doug > > On 05/30/2011 08:06 PM, Yang wrote: > > Thanks Doug. > > > > regarding "adding or removing fields from a returned record type should > > work", > > this is actually what triggered my investigation at first, and my tests > > seem to show that > > it's not the case: > > > > please see the attached schema.tar , and you can see 2 dirs, "1/" is > > for server, "2/" is for client. > > they are created by slightly modifying the standard 1.5.1 distribution. > > to see the demo, you need > > to do (please change the "path_to....." params below accordingly ) > > > > mkdir demo > > cd demo > > tar xzf path_to_avro-1.5.1-src.tar.gz > > mv avro-src-1.5.1 1 > > tar xzf path_to_avro-1.5.1-src.tar.gz > > mv avro-src-1.5.1 2 > > ## the following overrides some files in standard distro > > tar xf path_to_schema.tar > > cd 1/lang/java/ipc > > mvn compile exec:java -Dexec.mainClass=org.apache.avro.SimpleServer &>log > & > > cd - > > cd 2/lang/java/ipc > > mvn -Dtest=org.apache.avro.TestSimpleClient test > > > > > > you will see that the test testClientDiffReturnType() fails with > > following exception: > > > ------------------------------------------------------------------------------- > > Test set: org.apache.avro.TestSimpleClient > > > ------------------------------------------------------------------------------- > > Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.392 > > sec <<< FAILURE! > > testClientDiffReturnType(org.apache.avro.TestSimpleClient) Time > > elapsed: 0.005 sec <<< ERROR! > > java.lang.ClassCastException: org.apache.avro.test.evolution.Kind cannot > > be cast to java.lang.CharSequence > > at org.apache.avro.test.evolution.TestRecord.put(TestRecord.java:28) > > at org.apache.avro.generic.GenericData.setField(GenericData.java:463) > > at > > > org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:166) > > at > > > org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:138) > > at > > > org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:129) > > at > > > org.apache.avro.ipc.specific.SpecificRequestor.readResponse(SpecificRequestor.java:77) > > at org.apache.avro.ipc.Requestor.request(Requestor.java:153) > > at > > > org.apache.avro.ipc.specific.SpecificRequestor.invoke(SpecificRequestor.java:55) > > at $Proxy8.echo(Unknown Source) > > at > > > org.apache.avro.TestSimpleClient.testClientDiffReturnType(TestSimpleClient.java:111) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:616) > > at > > > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) > > at > > > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > > at > > > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) > > at > > > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > > at > > > org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) > > at > > > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) > > at > > > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) > > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > > > > > > > > the above error shows that avro on the client result parsing step tries > > to convert the old TestRecord.kind (second field) to the new > > TestRecord.extra_field, which is also the second field. so we get an > > error. so that's why I say that it seems not to be doing return schema > > conversion for me. maybe I need to do something to enable that? > > > > Thanks a lot > > Yang > > > > On Mon, May 30, 2011 at 12:36 AM, Doug Cutting <[email protected] > > <mailto:[email protected]>> wrote: > > > > On 05/26/2011 10:10 PM, Yang wrote: > > > I guess the schema resolution is done only on input params, and not > on > > > return value? > > > > The same resolution should be done on return values. For example, > > changing the return value from one record to another would not work > > (unless you used aliases) but adding or removing fields from a > returned > > record type should work. > > > > > incidentally, I found that if I keep the name of an enum type , > but > > > add new enum values to it (at the end of the value list), and then > use > > > the enum type as the return > > > type of my RPC call, it still works, although strictly speaking, > the > > > enum type has already changed. but this is probably quite a > dangerous > > > hack. > > > > That should not be dangerous. Avro translates enum values so that > > adding & removing symbols is permitted. As long as the reader's > schema > > still has the symbol that the writer sends things should work. > > > > Doug > > > > >
