Jsonapi-resources: Cross namespace relationships

[lgebhardt]

The problem:

Right now namespaces are assumed to be used for versioning, though they could also be used for separating entire sets of resources in isolated namespaces. JR does not currently support resource relationships which cross namespaces. #893 attempts to solve this, but as I brought up in the comments there is the potential for the system to encounter a situation where the correct behavior is ambiguous or will be inconsistent depending on the order of serialization.

Proposal:

A simple set of resource resolution rules could be used to solve this issue without the need to specifically mark up relationships definitions on a resource.

Rules:

• All resource resolution will take place relative to the namespace of the request ("Request Namespace").
• Related resources will be assumed to be in the Request Namespace.
• Resource definitions will support a new method called global_resource which will register a resource type in a "Global Resource Map" to this resource class.
• Declaring two resources classes with the same type as global_resource will raise an exception or emit a warning, which should catch conflicts during development.
• If a resource class does not exist in the Request Namespace the Global Resource Map will be consulted for the resource class.
• Resources created from the Global Resource Map will still follow same resolution rules starting with the Request Namespace. In other words relationships in a global resource will first resolve based on the Request Namespace.

I believe these rules should allow unambiguous resolution of resources and prevent runtime issues where a resource is serialized with differing sets of rules (resource definitions), and meet the intent of #893.

Let's discuss this and other proposals here. I haven't tried to code this, but I think it's possible to modify the code to support these rules without a lot of refactoring. If you see potential road blocks in either this project or your projects please raise them here.

[senid231]

nice solution
it will solve problem described in #893, so i will close it

[dwillett]

My current project could really use this flexibility. We have an additional admin namespace in our resource definitions that does not match the module prefix for the associated models, and I'm struggling to fully workaround the current strategies of resolving resource classes. Happy to offer more details as there may be a way I'm not seeing, but I think @lgebhardt's solution would work for us

[toobulkeh]

We could really use namespacing to sort hundreds of models in a single complex application.

There's only so many times we can name something "Environment" 😄

[gabrielwillemann]

Which version this feature will be release?

[rafaelpivato]

Resources created from the Global Resource Map will still follow same resolution rules starting with the Request Namespace. In other words relationships in a global resource will first resolve based on the Request Namespace.

I would disagree on this. My understanding is that the global resource would have its relationships solved against its own namespace then. That would allow a global resource to use other resources local to its namespace.