How to implement non integer default auto fields

Django Internals ORM
1

Hi, I’m developing the django backend for CrateDB, as we are a distributed database we do not support auto sequential integer generation, hence some form of random generation is need for unique PKs, we use elasticflakes (somewhate similar to uuid4).

I’d like my users to be able to do something like:
DEFAULT_AUTO_FIELD = "cratedb_django.fields.UUIDField" but non integer auto field are not supported, as seen in #32577 (Add support for `UUIDAutoField` `DEFAULT_AUTO_FIELD`) – Django

I’ve read https://github.com/django/django/pull/18365 and Db default UUID pk by nessita · Pull Request #24 · nessita/django · GitHub but it looks to me that there is still no way of me implementing this, currently I’m doing something like:

    CRATE_SQL_AUTO_BIGINT = "bigint default (random() * 2^63-1)::bigint"
    CRATE_SQL_AUTO_INTEGER = "integer default (random() * 2^31-1)::integer"
    CRATE_SQL_AUTO_SMALLINTEGER = "smallint default (random() * 32767)::smallint"
    data_types = {
        # todo pgdiff - doc
        "AutoField": CRATE_SQL_AUTO_INTEGER,
        "BigAutoField": CRATE_SQL_AUTO_BIGINT,
        "SmallAutoField": CRATE_SQL_AUTO_SMALLINTEGER,
         ...

To have ‘randomness’ and integers for the PK, but this is not as robust as I’d like.

Am I missing anything or is it true that non-integer default auto ids are still not a thing, unfortunately?

2

Hello @surister,

Am I missing anything or is it true that non-integer default auto ids are still not a thing, unfortunately?

They are still not a thing.

Until we deprecate DEFAULT_AUTO_FIELD in favor of a more lax DEFAULT_PK_FIELD that allows any type of field that either have a default or db_default option set (and thus is db_returning = True) your best option is to define a field class inherits from UUIDField and AutoField and override all the methods that are problemtatic.

This is necessary to bypass a hardcoded check that DEFAULT_AUTO_FIELD references subclass AutoField

1 Like
3

That’s what I feared, I didn’t like the random number generation thingy and was trying to avoid patching an inheritor class. But seems I don’t have an alternative, thanks!

If you guys need any feedback/help from a database implementor that is not the typical SQL model (as postgres/mysql) while improving this situation let me know, I’m always happy to help/contribute.

Cheers.