Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I did some work on allowing schema fields to be renamed in the generated model. This would to be to address Issue #17, but may also help if a schema field name conflicts with another method on an Avromatic model.
If this goes forward, I think that "aliases" should be changed to something like "renames" to avoid confusion with aliases in Avro schema names, and to make it clear the original field name is not available on the model.
It's also unclear what is the most natural way to configure this. In this code, the configuration is based on the field names within a schema, including nested fields. Would it be better to configure renaming scoped by the record type name instead of the field name within a record?
There still some work to do on validating the renames/aliases.
These changes also raise the question of whether there are too many methods defined on model instances by Avromatic. For example, there is a set of methods delegated to the class. Should these instead be called directly on the class to avoid field conflicts, or should a prefix be used to reduce the chance of a name collision. This should probably be handled separately.
I think the changes to
Avromatic::Model::Attributes
here also suggest that this module should be refactored. Instead of passing around information about the field/attribute currently being processed we could introduce anAttributeBuilder
class that holds the context and responds to methods providing what should be generated for that attribute.Prime: @jturkel