Closed shawnsarwar closed 6 years ago
Thanks for the report, I'll try to repro and get back to you.
Thanks for the bug report! I managed to reproduce the case you submitted. Turns out there were two bugs that interacted here. One is an issue with how the namespaces were being processed internally inside spavro, as it has it's own tracking for the recursive writer functions outside the schema parsing pass. It wasn't honoring the 'if it has a dot in the name it's the fully qualified name' part of the spec. The second is that when processing records, spavro checks the datum to see if it conforms to the schema for matching in Union schemas. The 'array' check code wasn't making sure that the datum was iterable before trying to verify that it matched the array schema, leading to an exception when trying to iterate over non lists.
commit with changes: 2c99b3f7da7d26ab4a09758ec2f25ef387214d2a
Let me know if this fixes the issue for you, I've pushed a new version of spavro 1.1.11 to pypi as well with the fix(es).
Let me know, @shawnsarwar, if you're OK with me closing this issue.
I haven't heard anything so I'm closing this, I believe it is fixed.
I need to turn on notifications. I didn't see this until it had been closed. I'll test and if it's not resolved I'll open a new ticket referencing this one.
I'm getting the exact same error with spavro 1.1.15. I'm running it in pipenv so I'm pretty sure I'm running on the right version. The only apparent thing to change is the line number of the throwing error.
"spavro": {
"hashes": [
"sha256:25e2994564df461baf739d2825e2451d5875de5583d0ed8c92070738661a6f4a"
],
"version": "==1.1.15"
}
Since the detail of the issue are the same I'll hold of opening a new ticket unless I hear from you.
Traceback (most recent call last):
File "src/spavro/fast_binary.pyx", line 705, in spavro.fast_binary.get_writer
File "src/spavro/fast_binary.pyx", line 499, in spavro.fast_binary.make_union_writer
File "src/spavro/fast_binary.pyx", line 363, in spavro.fast_binary.get_check
File "src/spavro/fast_binary.pyx", line 367, in spavro.fast_binary.make_record_check
File "src/spavro/fast_binary.pyx", line 363, in spavro.fast_binary.get_check
File "src/spavro/fast_binary.pyx", line 411, in spavro.fast_binary.make_union_check
File "src/spavro/fast_binary.pyx", line 363, in spavro.fast_binary.get_check
KeyError: 'org.eha.demo.parents'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "./test.py", line 68, in <module>
test(obj, schema)
File "./test.py", line 42, in t2
with DataFileWriter(bytes_writer, DatumWriter(), avsc, codec='deflate') as writer:
File "/home/sarwar/.local/share/virtualenvs/avro-check-in6pzLTy/lib/python3.5/site-packages/spavro/datafile.py", line 99, in __init__
self.datum_writer.writers_schema = writers_schema
File "/home/sarwar/.local/share/virtualenvs/avro-check-in6pzLTy/lib/python3.5/site-packages/spavro/io.py", line 820, in writers_schema
self.write_datum = get_writer(parsed_writer_schema.to_json())
File "src/spavro/fast_binary.pyx", line 709, in spavro.fast_binary.get_writer
KeyError: 'union'
Ok I've got a new process for uploading to pypi and it somehow failed to get the C code for the extension in v1.1.15. I've uploaded a new version v1.1.16 that should have the updated extension. Let me know if that version works and I'll close this.
Argh and the docs broke on pypi again this new pypi is a pain in my butt.
I'll leave this issue open until I hear from you @shawnsarwar (not sure if you turned on notifications).
Thanks! I'll take a look and report back on Monday.
Working as advertised. Thanks!
Good, I'm glad. I'd love to get your experiences using Spavro. How did you find it? Has it been easy to work with? Performant? I'm debating whether to publicize it more.
Our current applications for avro aren't terribly performance sensitive yet, so the primary impetus for choosing spavro was the API compatibility with the "official" lib and between python 2 & 3. On all those fronts it's been great. Normally I'd be hesitant to use something like spavro ( non-trivial complexity, using c extensions where I don't yet require performance, competing with a more official implementation ), but avro and avro-python3 are so neglected, I think you've got a great case for wide adoption.
I'm trying to serialize a message with its schema, but I'm getting the following error from spavro:
I can perform the operation in both avro and avro-python3. Also, the message validates against the schema in avro, avro-python3 and spavro.
Here is the function in question:
The schema is:
The message body is: