Learning Center

Learning Center

Learn Menu

Data Types

This article explains all the supported data types and how/when to use them. Since Enums currently support only int and string data types, you will most likely apply this knowledge whilst working with Classes.

We did our best to accommodate the needs of most languages/databases. Data types break down into several categories.


  • Standard: Mostly primitive and very common data types that every programming language/database supports in a way. For example string data type.
  • Entity: A data type that references another entity. For example, imagine you created two classes, Person and Dog. A person may have a dog, so you would add a dog property. You would most likely set the data type to Dog, which would reference the Dog class.
  • Array: An array of arbitrary data type. It may be an array of integers, strings, or even entities. Syntax: [int], [Person]
  • Map: A map/dictionary (key/value) representation of arbitrary types. Note that the key doesn't have to be a string. It can be any type as long as your engines' languages/databases support it. Syntax: {string:string}, {string:[int]}

Important: The UI hints only standard data types as you type, but you may fill out any complex data type, such as an array of Person class: [Person]


Every data type supports the following flags. Note that if a flag is used in a data type, and it's not supported by one of your engines, the target code may omit the given flag.

  • Optional: Simply place a question mark behind the data type: int?, Person?
  • Pointer: Prefix a data type with an asterisk: *string, *User
  • Reference: Prefix a data type with a reference: &string, &Person

Important: Each flag may only occur once at most. In other words, it's not possible to chain pointers to a data type right now (popular in languages like C++), for instance **string would not work.


Here's the list of all standard data types you can use. We support a lot of different integer types, to give you an option for an effective design. At the same time, we realize some projects may not care what type of integer is used whatsoever. For those reasons, we added two types: int and uint. Using these, you basically say "I don't care what integer/unsigned integer it is, just use whatever default integer type in each engine".

Some engines may not support such granularity. JavaScript engine might be a good example of that. There's only one number type. Make sure to check out the article for each engine you're planning to use - every article includes a list of data types and how they are interpreted in the given engine.

Data Type Note
bool true/false value
int default integer type (engine decides)
int8 range -128 to 127
int16 range -32,768 to 32,767
int32 range -2,147,483,648 to 2,147,483,647
int64 range -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807
uint default unsigned integer type (engine decides)
uint8 range 0 to 255
uint16 range 0 to 65,535
uint32 range 0 to 4,294,967,295
uint64 range 0 to 18,446,744,073,709,551,615
float floating point number (size depends on engine)
double double floating point number (size depends on engine)
string a string of characters
char a single character
date date representation type
datetime date & time representation type

Date Formatting

OneGen's raw date/time representation is the ISO 8601 format. All OneGen engines aim to parse date from/to this format, although it might become configurable in the future.

Why ISO 8601?

It's a standard date/time format that's readable (for instance, when reading a JSON response body) and it's supported by most JSON parsing libraries.


Since this is an essential part of your model design that you actually have to learn the syntax of, let's do a few examples, so you get the hang of it.

These examples are written in our Genesis language, make sure you're familiar with that.

User model

Imagine we want to design a User model for our app. The following would be the properties we'd add through the OneGen desktop app.

  • id: int. A mandatory integer id of our user.
  • username: string. We also need a username.
  • password: string. Password is a mandatory string as well. Even if it's hashed.
  • name: string?. Now, this is different. Check out the question mark at the end. That's right! The name is an optional string, so our users don't have to share it with us.
  • created: datetime. The date & time when the user record was created. We'll use this field for internal purposes.
  • newsletter: bool. If true, the user is opted to receive our newsletter.

A person and a Dog

In this example, we'll look at one-to-one relationship. We'll have two models, Person and Dog where the Person class will have a property to reference a dog.

dog: Dog

Simple, right? What if not every person has a dog? We could just make the field optional.

dog: Dog?

Now, what if a person may have more dogs? We could just turn the data type into an array.

dog: [Dog]

While we recommend using an empty array to denote no value, you could technically make the array optional if you'd prefer:

dog: [Dog]?

We use cookies to track activity using Google Analytics & reCAPTCHA. It helps us understand what our visitors like about our product and how they interact with our website. For more information, check out our Privacy Policy.