e versa is valid as well.
>
> Obviously this is not the case. since symbol "S7" is not present in schema1
> and
> also it has no default value defined,
>
>
>
> On Fri, May 5, 2023 at 7:37 AM Brennan Vincent <mailto:bren...@umanwizard.com>> wrote:
Which one is the writer and which is the reader?
Sent from my iPhone
> On May 4, 2023, at 22:47, KV 59 wrote:
>
>
> Hi,
>
> I see that that java Avro compatibility check doesn't work as per
> specification for enum schema evolution. I have a the following schema
>> {
>> "type" :
Yes, I 100% agree. I would like to do a side project eventually of improving
avro_derive in the way you suggest (or replacing it with Serde). I just haven't
gotten around to doing so. But what we have is working for Materialize for now.
> On Feb 17, 2022, at 10:00 PM, Askar Safin wrote:
>
> >
(To clarify: we have NOT licensed that entire Materialize repo under Apache
v2.0. I am only referring to the `avro` and `avro-derive` crates).
> On Feb 17, 2022, at 1:11 PM, Brennan Vincent wrote:
>
> By the way, we have what we believe to be the most correct and comp
r than
using the outdated version on crates.io <http://crates.io/> .
> On Feb 17, 2022, at 11:35 AM, Brennan Vincent wrote:
>
> Hello,
>
> Why was I included in the To: field of this e-mail; do you have a
> question/comment for me specifically?
>
>> On
Hello,
Why was I included in the To: field of this e-mail; do you have a
question/comment for me specifically?
> On Feb 17, 2022, at 10:47 AM, Askar Safin wrote:
>
> Hi.
>
> To all: it seems my language was too strong. I'm sorry about this. But I still
> don't plan to fill separate bug
"d",
> "fields": []
> }
> }
> ]
> }
> }
> ]
> }
>
> Now is the interior one "a.d" (since "a.b" is a fullname, so it implicitly
> creates a namespace of "a"), or is
It is a.c
> On Dec 27, 2021, at 9:42 AM, Askar Safin wrote:
>
> Hi. I'm writing Avro implementation in Rust for personal use. I have a
> question. Consider this Avro scheme:
>
> {
> "type": "record",
> "name": "a.b",
> "fields": [
>{
> "name": "c",
> "type": {
>
Hello,
I am a bit confused about the intended meaning of Parsing Canonical
Form. The spec suggests that when reducing a schema to PCF, only a
particular subset of fields should be retained:
[STRIP] Keep only attributes that are relevant to parsing data,
which are: type, name, fields,
We are generating some Avro schemas where some type names had a leading
dot, to indicate the null namespace. For example:
```
{
"type": "record",
"name": ".envelope",
"fields": [ ... ]
}
```
This seems fine according to my reading of the 1.9.2 spec, but
explicitly disallowed by
10 matches
Mail list logo
