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.
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]
Flags
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.
Standard
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.
Examples
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]?