Edgemorph Hierarchy Spec

Hierarchy

0000000000*: EdgeDB DSN                   [enumerated] ; Warning: Do not exceed 128 EdgeDB DSN connection strings!
000000000*0: EdgeDB database name         [enumerated]
00000000*00: Schema name                  [enumerated]
0000000*000: Module name                  [enumerated] ; Warning: Do not exceed 128 EdgeDB Module name strings!
000000*0000: Primary Command              [enumerated]
00000*00000: Secondary Command (Optional) [enumerated]
0000*000000: Ternary Command (Optional)   [enumerated]
000*0000000: Qualified type name or Function name (declared on 0000000*000) ; Warning: Do not exceed 128 total distinct type names or functions!
***00000000: Slice identifier mapped to the linear combination of ordered Namedtuple-like structs
             Depending upon the cardinality of a given module, Edgemorph's naming hierarchy can
             theoretically support both small and large database requirements. For more lightweight
             applications, Edgemorph can treat '***' as unordered distinct characters to achieve
             an upper limit of 341,376 ORM-like operations for one module. However, if Edgemorph needs to support
             a significantly large collection of types in one module, then it can be expanded to support up to
             2,097,152 distinct ORM-like operations by permanently upscaling from 'combination' mode
             to 'permutation' mode.
             If both of these thresholds are exceeded (which should only ever happen at some place like Google, Netflix, or Amazon),
             then the implementor *must* partition their project into 2, 3, or 4 projects. Alternatively, the schemas could be refactored
             to equally distribute object hierarchies across multiple different namespaces (either as schemas or modules depending on
             the circumstance).