Are 'schema name' and 'type key' used interchangeably?


If not, can you provide an example of when and how each should be used?

Can 'schema name' and 'type key' be used in the same C3 Type declaration?

According to me:

Use schema name when you create a db table from scratch:
The schema name basically identifies the table you are creating.

  • entity type MyType schema name ‘AAA’
  • entity type MyType mixes SomeOtherType schema name ‘AAA’
  • entity type MyType schema name ‘AAA’ {
    collectionField: [AnotherType] schema name ‘BBB’

Use type key when you extend an existing db table:
The type key is a suffix that identifies those rows

  • entity type MyType extends BaseType type key ‘X’
  • entity type MyType extends BaseType mixes SomeOtherType type key ‘Y’

Follow-up questions:

  • If you extend and mix does the order matter?
  • Is schema name for a collection field that is based on a foreign key?


Thanks, @romain.juban. To answer your question about the order of extend and mixes- yes, it does matter. You have to use extend first and then mixes. Else, it throws an error.


You do not have to use schema name for foreign key collection fields. This is because those are essentially ‘virtual fields’. There is no database column or table backing them up, they are produced at query time according to the rules provided in the fkey notation.

This is the same for (non-stored) calc fields, they don’t get stored and therefore don’t need a schema name. stored calcs on the other hand do require a schema name.


@rileysiebel can you explain why we can have a type key on the extended type?

Also are schema names required only for maps and arrays or also for sets?


@romain.juban The type keys are used on extendable/extended types and are used to populate the typeIdent field, which identifies what the “real” type of any instance is. That’s how we can tell a Facility from a Boiler for an instance, for example. The schema name (should generally use ‘schema suffix’, is used to create the necessary column names/table names, when there are nested included types and non-fkey collection fields.