Examples or guides for creating types, fields, relations?

API & Programming
1

Hi, I’d like to try to programmatically create an entire schema “from scratch” via the API. Browsing the API docs, I think I understand how to create types, but I don’t quite understand how to create relations between types.

For example, from reading the API docs I see two apparently relevant commands: schema.field/create and schema.type/create — am I supposed to create the types first, and then create the relation fields in a subsequent command, and then add the fields to the types in yet another subsequent command? Or is it possible to create the relations on the fly while creating the types, by including relations in the list of type fields?

I’m not sure that makes sense, but another way to approach this would be: it’d be super helpful if I could see some example code of calling the API in order to create types and create relations between those types. I mean not just simplistic examples that show the syntax of each command, but realistic examples based on use cases that show workflow, order of operations, etc.

Thank you!

2

You might want to check this out

1 Like
3

Thanks @Chr1sG!

I found the JavaScript code in that Metamodel app/template thing, and reading it over, it seems as though the idea is to create the types first (and while doing so one can only include fields that already exist) then create additional fields, then create relations.

Is that right?

4

Not sure what you mean by this.
Basically, you create the necessary types (databases) with mandatory fields plus any desired primitive fields (number, text, date etc.)
Then you can create relations between types by adding pairs of fields, representing the links as viewed from one database to the other.

5

I’m probably not using the right terminology, or just not making sense, because I don’t yet understand Fibery’s internal model.

Emphasis mine — aha, that’s helpful, you can include fields when creating a type, but only primitive fields — I didn’t see that anywhere.

Makes sense, thanks!

Although… it’s a little surprising we have to manually/mechanically express both sides of the relation. NBD, just curious: if the two fields that make up a relation are mirror images of each other, why not specify one side and have the API derive the other side? Is it so we can customize the name on each side?

6

Well, the two fields are not ‘mirror’ images, since a relationship can be 1-1, 1-n, n-1 or n-n.
The easiest way to define the relationship cardinality is to define each end of the relationship as either 1 or n.
And yes, it also allows you to choose the name of the relationship as viewed from either direction.

1 Like
7

makes sense, thanks!

8

BTW, is there any documentation on the concept of a non-primitive field? I’m a little fuzzy on when I’d want/need to use one.

9

Strictly speaking, they primitives are described here:

From a user’s point of view, they appear on the UI as:

Text,
Number,
Date,
Checkbox,
URL,
Email,
Phone,
Emoji

Non-primitives are all the rest:
rich-text, single selects, multi selects, relations, lookups, formulas, assignees, workflow, files, documents, whiteboards, comments, avatar

See my later post for more detail.

10

Thanks, but I’m not sure I understand. That list is almost but not quite the same as the list in the API docs of primitive field types:

fibery/int
fibery/decimal
fibery/bool
fibery/text
fibery/email
fibery/emoji
fibery/date
fibery/date-time
fibery/date-range
fibery/date-time-range
fibery/uuid
fibery/rank
fibery/json-value

So could you please help me understand the difference between primitive field types and non-primitive types? What even is a non-primitive field type? Is that the correct term? What are some an examples of non-primitive field types? Is there a list in the docs somewhere? Or are they composed ad-hoc of the primitive types?

Or maybe, just looking at the structure of the API docs, maybe the non-primitive field types are relations, single-selects, and rich-text fields, and maybe that’s it?

Sorry but I’m finding the docs terse and confusing.

11

Sorry, my previous post was providing info on primitive fields, not non-primitives, my mistake. I will update the post.

Primitives
Any number field (number, currency or percent) is stored as either fibery/int or fibery/decimal depending on the settings chosen by the user:

A checkbox field is stored as fibery/bool

A text field (not rich text field) is stored as fibery/text
Phone number, email and URL fields are also stored as fibery/text (they are just shown differently on UI)

A date field, can be either fibery/date, fibery/date-time, fibery/date-range or fibery/date-time-range depending on the selections made by the user.

Non-primitives
‘Non-primitive’ fields includes all the rest :wink: :
rich-text, single selects, multi selects, relations, lookups, formulas, assignees, workflow, files, documents, whiteboards, comments, avatar

One way to think about it is to think of primitive (basic) fields as the most simple characteristics of an entity (which can be stored as a single value).
In the real world, for a human being, this is things like: date of birth, height, name, shoe-size

Whereas the non-primitive (advanced) fields are the more complex characteristics, which can’t be stored as a single number/string etc.
In the real world, for a human being, this might be things like: siblings, educational achievement, number of children, etc.

There is no standard way of describing how a non-primitve field works, but I think for your case, the most important ones to understand are relations and select fields

(a multi-select is just a many-to-many version of a single-select field)

Assignees behave like a many-to-many relation to the User db
Workflow behaves like a single-select field

2 Likes
12

That was super helpful — thank you!