JSONAPI-Resources / JSONAPI-Resources/jsonapi-resources

Linked data with polymorphism does not work with custom `key_type`

Offen
#1,285 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Vorherrschende Sprache
Ruby
Sterne
2.3k
Forks
546
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

This issue is a (choose one):

  • Problem/bug report.
  • Feature request.
  • Request for support. Note: Please try to avoid submitting issues for support requests. Use Gitter instead.

Checklist before submitting:

  • I've searched for an existing issue.
  • I've asked my question on Gitter and have not received a satisfactory answer.
  • I've included a complete bug report template. This step helps us and allows us to see the bug without trying to reproduce the problem from your description. It helps you because you will frequently detect if it's a problem specific to your project.
  • The feature I'm asking for is compliant with the JSON:API spec.

Description

If you create a polymorphic association with custom key_type id is always taken which leads to a wrong data sharing.

Bug reports:

Everything is on lib/jsonapi/resource_serializer.rb:464
When calling source.public_send("#{relationship.name}_id"), it is fine (faster) but it does not take care about custom key_type.
But if you call source.public_send(relationship.name).try(:id), you're using the custom key_type.

Features:

We can set another argument to has_one to be able to mention that the key_type has been modified.
Here is my proposition:

# app/resources/my_awesome_resource
has_one :positionable, polymorphic: true, foreign_key: :positionable_id, foreign_key_type_changed: true

# jsonapi/resource_serializer.rb

  def foreign_key_value(source, relationship)
      # If you have changed the key_name, don't even try to look at `"#{relationship.name}_id"` 
      # just load the association and call the custom key_name
      foreign_key_type_changed = relationship.options[:foreign_key_type_changed] || false
      related_resource_id =
        if source.preloaded_fragments.has_key?(format_key(relationship.name))
          source.preloaded_fragments[format_key(relationship.name)].values.first.try(:id)
        elsif !foreign_key_type_changed && source.respond_to?("#{relationship.name}_id")
          # If you have direct access to the underlying id, you don't have to load the relationship
          # which can save quite a lot of time when loading a lot of data.
          # This does not apply to e.g. has_one :through relationships.
          source.public_send("#{relationship.name}_id")
        else
          source.public_send(relationship.name).try(:id)
        end
      return nil unless related_resource_id
      @id_formatter.format(related_resource_id)
    end

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne bei lib/jsonapi/resource_serializer.rb:464 und untersuche foreign_key_value, wobei du dich darauf konzentrierst, wie polymorphe Beziehungen ihre IDs erhalten, wenn ein benutzerdefinierter key_type konfiguriert ist. Reproduziere den gemeldeten Fall und füge Testabdeckung hinzu, die zeigt, dass die ID der serialisierten Beziehung den benutzerdefinierten key_type berücksichtigt, statt immer die direkte ID der Zuordnung zu verwenden.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
rails, ruby
Bereich
api, backend
Issue-Typ
Bug
Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Aktivitätsstatus
Veraltet
Klarheit
Klar beschrieben
Anfängerfreundlichkeit
52/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.