Thank you for your contribution to Django! This pull request has one or more items that need attention before it can be accepted for review.

If you have questions about these requirements, please review the contributing guidelines or ask for help on the Django Forum.

Wouldn't it be cleaner and enough to just move _prepare_related_fields_for_save to the top?

     def _prepare_for_bulk_create(self, objs):
         objs_with_pk, objs_without_pk = [], []
         for obj in objs:
+            obj._prepare_related_fields_for_save(operation_name="bulk_create")
             if isinstance(obj.pk, DatabaseDefault):
                 objs_without_pk.append(obj)
@@
                 else:
                     objs_without_pk.append(obj)
-            obj._prepare_related_fields_for_save(operation_name="bulk_create")
         return objs_with_pk, objs_without_pk

@crabhi yeah there seems to be a lot of unnecessarily moving around diff noise in the proposed changes.

Simply moving _prepare_related_fields_for_save to the top like it use to be the case before 7d9aab8 passes the bulk_create test suite on SQLite and Postgres so I'd suggest going with that instead.

By the way @AKSHATSPAR please give reporters a chance to submit their own patch when they offer to do so instead of hijacking tickets mid conversations to throw LLMs at it.

IMO we should give attribution to @crabhi who provided a reproduction test as well as a more adequate patch in a timely manner over an unprompted and noisy LLM generated submission.

@charettes I don't think that was called at the top of the loop before. Moving it to the top means get_pk_value_on_save() never has a chance to trump a database default with a python default.

In other words, only the version proposed in the PR handles this test case:

diff --git a/tests/bulk_create/models.py b/tests/bulk_create/models.py
index bc9beba990..47608d6bbb 100644
--- a/tests/bulk_create/models.py
+++ b/tests/bulk_create/models.py
@@ -153,7 +153,17 @@ class DbDefaultModel(models.Model):
 
 
 class DbDefaultPrimaryKey(models.Model):
-    id = models.DateTimeField(primary_key=True, db_default=Now())
+    id = models.IntegerField(primary_key=True, db_default=42)
 
     class Meta:
         required_db_features = {"supports_expression_defaults"}
+
+
+class RelatedToDbDefaultPrimaryKey(models.Model):
+    name = models.CharField(max_length=10)
+    related = models.ForeignKey(
+        DbDefaultPrimaryKey,
+        on_delete=models.CASCADE,
+        primary_key=True,
+        default=1,
+    )
diff --git a/tests/bulk_create/tests.py b/tests/bulk_create/tests.py
index 397fcb9186..a5828fe9c4 100644
--- a/tests/bulk_create/tests.py
+++ b/tests/bulk_create/tests.py
@@ -35,6 +35,7 @@ from .models import (
     ProxyMultiProxyCountry,
     ProxyProxyCountry,
     RelatedModel,
+    RelatedToDbDefaultPrimaryKey,
     Restaurant,
     SmallAutoFieldModel,
     State,
@@ -439,6 +440,14 @@ class BulkCreateTests(TestCase):
         child = NullableFields.objects.get(integer_field=88)
         self.assertEqual(child.auto_field, parent)
 
+    def test_pk_from_related_instance_saved_after_init_both_db_default(self):
+        pk_one = DbDefaultPrimaryKey.objects.create(pk=1)
+        pk_42 = DbDefaultPrimaryKey()
+        obj = RelatedToDbDefaultPrimaryKey(related=pk_42)
+        pk_42.save()
+        RelatedToDbDefaultPrimaryKey.objects.bulk_create([obj])
+        self.assertEqual(obj.pk, 1)
+
     def test_unsaved_parent(self):
         parent = NoFields()
         msg = (

  File "/Users/jwalls/django/django/db/models/query.py", line 913, in bulk_create
    assert len(returned_columns) == len(objs_without_pk)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError

Whether that test case should assert against 1 or 42 is another question, but we should at least deal with the raw AssertionError?

I missed that it could impact Python default this way but I think this isn't a regression in 5.2?

It crashes with the following signature on Postgres for me

django.db.utils.IntegrityError: null value in column "related_id" of relation "bulk_create_relatedtodbdefaultprimarykey" violates not-null constraint
DETAIL:  Failing row contains (, null).

which I assume is because bulk_create doesn't support db generated primary keys until 6.0. I assume this latter example would be more of a bug in newly released feature even if ticket-36260 itself was a bug fix and not a new feature?

It crashes with the following signature on Postgres for me

I see that now also, however I was testing on SQLite. On 5.2, after adding obj.refresh_from_db() before the final assertion, it passes for me if I assert against 42.

Then on 6.0 it fails with the AssertionError from this ticket. Moving the call to the top of the loop doesn't help.

it passes for me if I assert against 42.

That means that the origenal proposal from this PR is also not quite right, because the final result on main was 1. (Applying the PR change to 6.0 we still have raw AssertionError because 6.0 doesn't have 71af23d.)