schemaVersion: The current version of the database schema. This is used by the
*OpenHelpers classes to migrate between schema versions. If you change your entity/database schema, this value has to be increased. Defaults to 1.

daoPackage: The package name for generated DAOs, DaoMaster, and DaoSession. Defaults to the package name of your source entities.

targetGenDir: The location where generated sources should be stored at. Defaults to the generated source folder inside the build directory (
build/generated/source/greendao).

generateTests: Set to true to automatically generate unit tests.

targetGenDirTests: The base directory where generated unit tests should be stored at. Defaults to
src/androidTest/java.

Basic properties

Java

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

@Entity

publicclassUser{

@Id(autoincrement=true)

privateLongid;

@Property(nameInDb="USERNAME")

privateStringname;

@NotNull

privateintrepos;

@Transient

privateinttempUsageCount;

...

}

The @Id annotation selects a
long/
Long property as the entity ID. In database terms, it’s the primary key. The parameter autoincrement is a flag to make the ID value ever increasing (not reusing old values).

@Property lets you define a non-default column name, which the property is mapped to. If absent, greenDAO will use the field name in a SQL-ish fashion (upper case, underscores instead of camel case, for example
customName will become
CUSTOM_NAME). Note: you currently can only use inline constants to specify a column name.

Defaults

greenDAO tries to work with reasonable defaults, so developers don’t have to configure each and every bit.

For example the table and column name on the database side are derived from the entity and property names. Instead of the camel case style used in Java, the default database names are in uppercase using an underscore to separate word.

For example, a property called
creationDate will become a database column
CREATION_DATE.

Relations

Triggering generation

Once your entity schema is in place, you can trigger the code generation process by using “Make project” in your IDE. Or by directly executing the
greendao Gradle task.

If you encounter errors after changing your entity classes, try to rebuild your project to make sure old generated classes are cleaned.

Modifying generated code

Entity classes in greenDAO 3 are created and edited by the developer. However, during the code generation process greenDAO may augment the source code of entities.

greenDAO will add a @Generated annotation to methods and fields it created, to inform the developer and to prevent any loss of code. In most cases, you should not have to touch code annotated with @Generated.

As a precaution, greenDAO will not overwrite existing code and raise an error if generated code was manually changed:

As the error message implies, there are usually two ways to resolve this:

Revert the changes to code annotated with @Generated. Alternatively, you can also delete the changed constructor or method completely. They will be regenerated with the next build.

Replace the @Generated annotation with a @Keep annotation. This will tell greenDAO to never touch the annotated code. Keep in mind that your changes might break the contract between the entity and the rest of greenDAO. Also, future releases of greenDAO might expect different code in generated methods. So, be cautious! It’s a good idea to have unit tests in place to avoid trouble.

Keep sections

KEEP sections used in older versions of greenDAO are no longer supported.

However, if the Gradle plugin detects a
KEEP FIELDS section it will automatically annotate fields inside with @Transient. Afterwards, the surrounding
KEEP FIELDS comments may be removed.