Two failure cases of FastDeserializerGenerator

[volauvent]

We have seen two FastDeserializer generation failure cases -

1. Record with Nested Map fields
2. Record that holds union a branch of which is the record itself

These two issues have been fixed in the following PR:
linkedin/avro-util#46

Can you take a look of this PR to see if you need this fixup?

[flowenol]

Hi,

Thank you for pointing this out. I'll try to replicate these issues in our branch and provide fixup similar to yours. We haven't run into such issues so far, probably because none of our production schemas contain above scenarios.

[FelixGV]

Should we take another look at whether this fast-avro project should remain split between the RTB House and LinkedIn forks?

Since the last time we checked in about a year ago (in a discussion on issue #6), we've continued to invest significantly in this project to improve stability, performance and compatibility. We've got a few people from 3-4 teams contributing various improvements on the side. Since then, we also dropped our proprietary fork and migrated our internal projects to use the open-source one, so I believe the code is getting a good amount of production hardening.

If I understand correctly, the LI fork is a superset of the original on pretty much all dimensions, except for the fact we disabled the code gen cache (for reasons discussed in issue #6). If the cache is a mandatory feature to unify the two communities, I believe we could implement it in a way that's version-aware such that the concerns we cited are addressed.

We could do a video conference if you're interested in syncing up.

[flowenol]

Hi,

Sure, we can schedule a conference. In fact lately we don't invest much effort into this project as it fully meets our internal needs, except for occasional bugs.