How to set DataDefinition::create('integer') to allow bigint numbers I'm trying to create a FieldType in Drupal 8 which needs to be stored as bigint.
I set the field in the schema:

public static function schema(FieldStorageDefinitionInterface $field_definition) {
return array(
  'columns' =&gt; array(
    'value' =&gt; array(
      'type' =&gt; 'int',
      'size' =&gt; 'big',
      'not null' =&gt; FALSE,
      'unsigned' =&gt; TRUE,
    ),
  ),
);


}

I then added the propertyDefinitions:

public static function propertyDefinitions(FieldStorageDefinitionInterface $field_definition) {
$properties['value'] = DataDefinition::create('integer')
  -&gt;setLabel(t('Field value'));

return $properties;


}

When trying to add an integer of more than 9 digits I get following validation error:


  This value should be of the correct primitive type. 


How can I get this correct?

Thanks!
I do not believe there is a solution for this.

Typed Data Manager will always add the PrimitiveType validation constraint plugin for any primitive data type (data type implementing PrimitiveInterface). This plugin does not provide any options for the filter_var native PHP function, which is required to set max_range. This option itself must be less than the PHP_INT_MAX constant. Furthermore PHP_INT_MAX is signed and BIGINT is unsigned. 10 digits should be supported by PHP_INT_MAX for even 32-bit systems as long as it is below 2147483647, which is probably the case for your PHP build. You could try using a 64-bit version of PHP.

There are three alternatives given the signed/unsigned caveat above:


Create a Data Type plugin (that does not extend on PrimitiveInterface) to handle bigger integers.
Alter the constraint plugins and replace PrimitiveType with your own constraint plugin that allows for this or does its own logic. Hope that no other module will do this for the same plugin.
File a core issue and patch Drupal core so that Typed Data Manager allows to pass options and PrimitiveType plugin uses those options. This is trickier than it seems because those options would need to be a part of the DataDefinition (in a backwards-compatible API change), and then extracted out as options into the constraint.


My preferred way would be to get rid of PrimitiveType constraint altogether in Drupal 9 and use specific Symfony constraints.