Function first, performance later

When writing initial descriptor file versions or extending existing ones, assure user-friendly error-messaging by deactivating database batch operation (<database ... batch="false"/>). You can turn it on again when you are finished. for easily switching between configurations, you can make use of the staging mechanisms described in Section 7, “Staging”

Using externally provided SQL scripts

In most cases you will need to include files that are created and maintained outside you generation configuration, e.g. DDL files. You should resist from creating modifying a local copy of such files. Better refer to the original one or keep an unmodified copy. All changes you need to make should be applied in an extra script, e.g. by 'alter table' statements.

Extending benerator

There are many service provider interfaces which you can use to extend benerator. For most interfaces (e.g. Converter), benerator comes with an abstract implementation (e.g. AbstractConverter) that should be used as parent class for custom implementations. This assures optimum compatibility with future versions of benerator. If an interface will change, its abstract implementation will provide a default behavior or a workaround.

Validate generation results

You will always need some experiments for defining data generation. If you have complex dependencies, it is good practice to write a utility, that validates the generated data and signals failure by an exception. This could, e.g. be a Task implementation.

Clean up each time

When refining data generation, it is helpful, to always have the same base to start from. So, for populating databases, it is good practice to first call scripts, that first drop, then recreate all tables.