jminer / rust-avro Goto Github PK

You should be able to define a type and use in as the type of a record's field, or the type of an array, etc.

enum Seasons {
    SPRING, SUMMER, FALL, WINTER
}

record RoughDate {
    Seasons season;
    int year;
}

I'm not sure yet, but I'm leaning towards removing the lifetime parameter from Protocol. Lifetime parameter pro/cons:

Pros:

• Reduces the number of allocations the parser does. All identifiers (of records, fields, messages, parameters, etc.) can just be slices.

Cons:

• Since identifiers are just slices of the input, then the input needs to live longer than the slices. The IDL file contents has to be kept around as long as the protocol is used because the protocol borrows it. This could be annoying in some apps. This could be solved at the expense of adding a Protocol.to_static method that returns Protocol<'static>.
• Adding another lifetime parameter to whatever contains a reference to a protocol can get very annoying too.

Basically, the pro is performance and the con is ergonomics. I'm not convinced that IDL file parsing speed matters a lot. Most of Rust's JSON and XML libraries make it hard or impossible to do zero-copy parsing, and I think it matters a lot more for them.

Hello @jminer, We and other people @flavray + @poros + @RyanSkraba are trying to have a consolidated Avro implementation on Rust as part of the Apache Avro project.

flavray/avro-rs#189

For this reason I wanted to contact you because you are the current owner of the avro crate to see if you would be interested on sharing the crate name with us so we can publish future versions of Apache Avro into using the avro crate name.

We also contacted @Dandandan who generously accepted to donate to us the avro-tools name he used in his own project Dandandan/avro-tools-rust so we will be in a perfect situation if you accept to give us the access.

Sorry for coming out of the blue with this request but I expect you see the value for the rust and Avro communities.

Thanks,
Ismaël (current Apache Avro PMC Chair).

I've started working on support for encoding values, with the int64 as a starting point.

The API I'm going with is:

pub fn encode<W: Write>(writer: &mut W, schema: &Schema, value: &Value) -> Result<(), EncodeError>

Is this something you're interested in? I can open a PR if you want.

Parsing errors need to contain the line and column number of the error.

When parsing an IDL file, warn when a protocol/record/field name does not follow convention. There could be a annotation/property that changes what the naming convention should be, say @recordNaming("PascalCase") or @recordFieldNaming("snake_case") or @enumSymbolNaming("SCREAMING_SNAKE_CASE").

This warning would kind of be a nice usecase for an AST, so that the warning could be emitted after parsing, yet the line number still be reported. But I don't think it is enough reason to add an AST, so I'll just add the warning to the parser.