Giter Site home page Giter Site logo

Comments (12)

jasminb avatar jasminb commented on August 16, 2024

Hey,

It is a bit tricky to support it, only solution flexible enough would be forcing you to wrap all your relationship objects with JSONAPIDocument<?>.

Will give it some more taught, if you have any ideas, please share.

from jsonapi-converter.

Kylar42 avatar Kylar42 commented on August 16, 2024

Was thinking about this and have two proposals. One is simple, but clunky. One is more complicated, but more flexible.
The first is define a separate Map object in each Model that has a special annotation, like:

@RelationshipMeta(type="teacher")
Map<String, JsonAPIDocument<>>

The second is to do something similar, but with a Producer object that will return a JSONAPIDocument based on the relationship object during serialization time. :


@RelationshipMetaGenerator(type="teacher")
MetaProducer<T> objectProducer;

public interface MetaProducer<T>{
    JSONApiDocument metaForObject(T Object);//where this would be called for each Relationship object.
}


The more I think about it, the more I think the second is the way to go.

I can code a first draft next week and make a PR if you'd like.

from jsonapi-converter.

jasminb avatar jasminb commented on August 16, 2024

Hey @Kylar42, relationship can be either to one or many resources. So we need a wrapping object that will contain both the meta and the actual resources.

Now, during deserialisation, relationship can be either provided in included section, or not provided hence it needs to be resolved via provided link (this makes things complicated).

This leads to the solution that would basically force the following pattern:

public class MyClass {

@Relationship
private JSONAPIDocument<MyRelationshipClass> relationship;
}

Meta cannot be part of model since there are cases where no model is present just the links that can be used to fetch the actual model.

So, again, the biggest issue here is the fact that users will be forced to wrap relationship objects with JSONAPIDocument.

from jsonapi-converter.

Kylar42 avatar Kylar42 commented on August 16, 2024

In the case where you're just including a links, then the relationship that you return from the
/object/relationships/abcd call would then be responsible for returning the relationship and meta info as well, which would probably be it's own model, right? If I'm misunderstanding, can you give me a more concrete example? I've started trying the callback technique to see if it would work for me in a local fork.

from jsonapi-converter.

jasminb avatar jasminb commented on August 16, 2024

I'm not sure I understand the need for relationship meta than. Could it be looked at as the top-level meta for single resource? What if one resource has relationship to many other resources which in turn all would need to have different meta for that particular relationship?

from jsonapi-converter.

Kylar42 avatar Kylar42 commented on August 16, 2024

So here's a use case that's similar to what I'm dealing with:

a user has an 'asset' - in this case, it's a material that is a video on youtube.

Here's it's representation:

{
    "data": {
        "type": "material",
        "id": "video-123",
        "attributes": {
            "name": "Escape From New York Trailer",
            "videoType": "trailer",
            "length": "00:01:30"
        },
        "meta":{
            "license": "CCNA",
            "uploader": "[email protected]"
        }
    }
}

And this material could be referred to in a bunch of places by different resources.

Let's say I'm a teacher, and giving an assignment. So I reference this material, but I need to specify some metadata on the relationship like the start time of the clip and the duration inside the video to watch:

{
    "data": {
        "type": "assignment",
        "id": "kylar-assignment-1234",
        "attributes": {
            "name": "Watch A Video Clip From Youtube",
            "department": "Art",
        },
        "relationships": {
            "material": {
                "data": [
                    {
                        "type": "material",
                        "id": "video-123",
                        "meta": {
                            "starttime": "00:00:31",
                            "duration": "46s"
                        }   
                    }
                ]
            }
        }
    }
}

So in this case, I would need and want to specify different metadata for each relationship.

from jsonapi-converter.

Kylar42 avatar Kylar42 commented on August 16, 2024

So that's where I was thinking the callback/RelationshipMetaProducer would be a useful pattern. It could be both ways - a MetaConsumer/MetaProducer type of object so that we can read it back as well.

from jsonapi-converter.

jasminb avatar jasminb commented on August 16, 2024

Hey @Kylar42, what do you think about simply adding a new methods to the JSONAPIDocument:

One for cases where user has a type defined for relationship meta:

public <T> T getRelationshipMeta(Object source, Class<?> metaType) {
 ...
}

One of cases where theres no type:

public Map<String, ?> getRelationshipMeta(Object source) {
    ...
}

Internally, library would keep track of object/meta pairs and store it to JSONAPIDocument object.

from jsonapi-converter.

Kylar42 avatar Kylar42 commented on August 16, 2024

That seems good for reading the meta, but how would you generate it? Would I create the JSONAPIDocument, then have to set the meta on it separately for each object?

from jsonapi-converter.

jasminb avatar jasminb commented on August 16, 2024

Yes, you would have to register meta per object on the JSONAPIDocument. It has its pros and cons.

Slightly different approach would be defining RelationshipMeta annotation as you mentioned before, lib that would take whatever object is there and serialise it as relationship meta.

This means that if you have Student and Teacher models where every student has its teacher. If there was a need for meta on the Student -> Teacher relationship, Student would have the meta object attribute annotated with the new annotation and the name of the relationship (since there could be different relationships with different meta on same resource).

from jsonapi-converter.

rlazar avatar rlazar commented on August 16, 2024

+1 access for meta on relationships is needed.

from jsonapi-converter.

jasminb avatar jasminb commented on August 16, 2024

Hey @Kylar42,

Got some time so I wanted to see what can be done related to meta on relationships.

By taking another look at the example that you provided, you need to be able to have access to meta that is object level and not relationship level.

To summarise, currently it is not possible to access relationship-level meta objects but if on object level, there is meta available, it can be accessed by adding an attribute to relationship object and annotating it with Meta annotation.

From your example:

{
    "data": {
        "type": "assignment",
        "id": "kylar-assignment-1234",
        "attributes": {
            "name": "Watch A Video Clip From Youtube",
            "department": "Art",
        },
        "relationships": {
            "material": {
                "data": [
                    {
                        "type": "material",
                        "id": "video-123",
                        "meta": {
                            "starttime": "00:00:31",
                            "duration": "46s"
                        }   
                    }
                ]
            }
        }
    }
}

You would have following material class:

@Type("material")
public class Material {
# Other attributes

@Meta
private MaterialMeta meta;
}

public class MaterialMeta {
    private String startTime;
    private String duration;
}

For relationship level meta, new annotation will be introduced which allows specifying meta attribute that is related to a relationship.

public class MyType {

@Relationship("my-relationship")
private RelationshipType relationship

@RelationshipMeta("my-relationship")
private RelationshipMetaType relationshipMeta;

}

This allows for both reading/writing relationship meta.

Relationship level meta is meta attribute that is present on relationship level, as per spec:

A “relationship object” MUST contain at least one of the following:

  • links
  • related
  • data: resource linkage
  • meta: a meta object that contains non-standard meta-information about the relationship.

Example of relationship level meta:

{
  "data": {
    "type": "assignment",
    "id": "kylar-assignment-1234",
    "attributes": {
      "name": "Watch A Video Clip From Youtube",
      "department": "Art"
    },
    "relationships": {
      "material": {
        "data": [
          {
            "type": "material",
            "id": "video-123",
            "meta": {
              "starttime": "00:00:31",
              "duration": "46s"
            }
          }
        ],
        "meta": {
          "relationshipLevelMetaAttribute": "value"
        }
      }
    }
  }
}

from jsonapi-converter.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.