#26291: loaddata cannot deserialize fixtures with forward references and natural
foreign keys
-------------------------------------+-------------------------------------
     Reporter:  inglesp              |                    Owner:  nobody
         Type:  New feature          |                   Status:  new
    Component:  Core                 |                  Version:  1.9
  (Serialization)                    |
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:
                                     |  Unreviewed
    Has patch:  1                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by freakboy3742):

 @timgraham I've left some comments on the PR about specific implementation
 details, but the broad-strokes approach seems sound. Unlike PK references,
 Natural keys depend on being able to issue queries on the database, so
 there's no way to resolve a forward reference until the object actually
 exists. This means that deferring selected objects is the only approach
 that is going to work. I can't think of any situation where this will
 cause a regression in behavior - it just means a subset of all fixtures
 that wasn't previously loadable now will be. AFAICT, the code that Peter
 has added should only be activated in the case of fixtures that can't
 currently be parsed at all.

 The only alternative that I can see would be to improve
 `sort_dependencies` so that it only issued fixtures in a format that can
 be read again. However, that doesn't improve the general case that Peter
 has identified - fixtures generated by an external source.

 The dependency resolution issue that Peter flags *should* (AFAIK) only
 exist for natural key fixtures (for the reason identified previously), and
 MySQL InnoDB data stores (because InnoDB's implementation of referential
 integrity is demonstrably broken). On other data stores, forward PK
 references aren't an issue.

--
Ticket URL: <https://code.djangoproject.com/ticket/26291#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.0847e049f5979105fb40b68333d56d3a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to