...
| Directive | Description | Default | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| requireExplicitCollectionKeys | Directive indicating that map collections' contained entities must define an explicit field field to store the key for the entity when it is in the map. When this directive is false, it is possible that as the model evolves the implicitly generated key field could change and cause existing keys to be ignored on upgrade.
| false | ||||||||
| generateEmbeddedEntityInterfaces | Directive indicating that the generator should create interfaces for embedded entities. This can be disabled for applications with stringent performance requirements to reduce the overhead associated with multi-morphic vtable lookups. | true | ||||||||
| generateEmbeddedEntitiesNonFinal | When this directive is set to true the generated entity class is not declared as final nor are its accessors. This feature can be useful for applications that need to mock embedded entities in test frameworks such as CGLIB, but is not recommended for production use for performance reasons.
| false | ||||||||
| generateDefaultGetters | Whether or not to generate default getters that accept a value to return when the field is not set. Not typically recommended | false | ||||||||
| generateThrowOnUnsetGetters | Whether or not to generate getXXXOrThrow() or accessors that will throw an ERogFieldNotSetException when the field has not been set. This provides an alternative to calling hasXXX for a field to test if the field is unset. Usage of this directive is not recommended; hasXXX is the recommended approach to testing if a field is not set. Exception throwing is more expensive, and the generated getXXXOrThrow method introduces extra invocation overhead and a larger code size. | false | ||||||||
| generateRequiredFieldValidators | Whether or not validation logic is generated in the types validators for required fields. Enabling this leads large generated code size, and validation checks are expensive, so this is not recommended for performance sensitive applications. | false | ||||||||
| generateFluentSetters | Directive indicating that fluent style setters should be generated for fields. This can be enabled to generate fluent accessors on generated types. This can be useful for writing concise test code, but is more overhead, so it's usage is not typically recommended. | false | ||||||||
generateAllStringsPoolable | Directive indicating that all Strings fields in the model should be generated as poolable types regardless of the value of the field's poolable attribute. | false | ||||||||
| pooledStringFieldTypeNameSuffixPolicy | Can specify None, Always or OnConflict to instruct the code generator as to how to handle naming conflicts that arise from a pooled string field type name generated from a field name are suffixed to avoid a name clash. | "None" | ||||||||
| pooledStringFieldTypeNameSuffix | Specifies the suffice to use to resolve pooled string type name conflicts with Always or OnConflict suffixing policies. | "String" | ||||||||
| generateProtobufClasses | Specified that protobuf classes should be generated using the protoc code generator in addition to the encoding type specific generated classes. This directive only applies to Xbuf and Xbuf2 encoding types. | "String" |
It is recommend that new projects set this directive to true.
Running with Java
To run the generator with java you can use:
...