I hate to throw a spanner in the works, but this would be a lot simple if/when this is merged: #7515

Something along the lines of

class SerialField(model.Field):
    def __init__(self, *args, **kwargs):
        kwargs['readonly'] = True
        super(SerialField, self).__init__(*args, **kwargs)
   ...

@wengole yes, that would be cool, but whoever comes last hast to refactor ;) It is really only a couple of lines in both cases.

I changed a couple of things, I don't know tho, if this field is ready year. Currently every insert would result in an extra query, where the field should use RETURNING. I'm not too familiar with the db backends, to implement that properly.

Well, I'm currently writing a DEP targetting precisely this problem. Serial is just a part of a more generic problem we need solved once and for all. Do you want to participate on the DEP ?

(For the record : #7515 (comment) )

Hey guys,
Any news on this PR? We would love to use it in production and had to copy the implementation 🤓.

Thanks,
Arthur

We are waiting for this PR to be merged. Very useful

@syurchenko I will resume my work on this once #6385 is merged.
There is also a lager design issue, that is still to be resolved. Currently this field would execute an additional query for each insert. To be honest I know how to solve this in prostgres, I need to look into the ORM again, to see how I can make it work in Django.

@codingjoe #6385 is merged. Can I give you a bump to resume work on this? I know I'd like to see this feature land! We use uuid's but need serial int ids for other uses, so this would be a great addition to the postgres contrib. Thanks.

@codingjoe I ended up going off of what you had done in order to build a custom SerialField for our project. It worked great. If you want help with this PR and just don't have time to do it now, I could take a crack at it. Let me know?

I did add the below method, or else it wasn't creating the field in the database. But other than that, I pretty much went off of what you had:

class SerialField(Field):
    # ...
    def db_type(self, connection):
        return 'serial'

@aronysidoro yes sure, be my guest to try. I do have more time now, since my other big PR is merged, but I have another one too.
The big problem here is to add the RETURNING statement, that you only have a single query per insert.

@codingjoe ok, I am going to try. So, it sounds like the big problem would be when using the SerialField with a bulk insert? I didn't test for that, so I will test for that as well. Thanks for pointing that out.

@codingjoe I have looked into this several times. I just want to follow up. So far, I haven't seen where a single RETURNING statement could be injected.

One place I looked at in particular was django.db.models.query.QuerySet.bulk_create here:

https://github.com/django/django/blob/master/django/db/models/query.py#L458

It looks like the code is looking for objects without a pk to bulk return the ids, but in the case of a Postgres SerialField, it could be any field, not just the pk field.

It seems like the code would need to use the NEXTVAL regardless. If that's true, then I wouldn't have much to add to your PR because it did everything necessary.

Any thoughts?

Hi @aaronlelevier I know there isn't a simple way to inject this.
What I think needs to be done is:
Create a method to get a set of all fields that have a database default and should have a returning value, than rewrite those functions:

and this one:

They all need to be able to not only unpack a single but all values for the fields that are specified within your method.

btw, that method should return the fields in a deterministic order.

Does that help you?

@codingjoe thank you for your reply. I am going to look into your recommendations above.

Yes, it definitely helps. I was looking at Django 1.11, but I see the PR that you linked above is from Nov 29th, so there's new code then for some of the logic that SerialField could use that I hadn't seen.

Great, thank you.

See also https://code.djangoproject.com/ticket/29444

Thanks for the review @charettes, but this will have to wait until after #9983 anyways. I will close the PR for now and open it, once #9983 is merged.

@codingjoe I notice the PR you mentioned has been merged, should this be reopened?

@knyghty I already opened a new PR for that, see #11568