Comments (12)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
+1 access for meta on relationships is needed.
from jsonapi-converter.
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)
- @Id obfuscated by proguard even after excluding the annotation HOT 2
- POST Example with RestTemplate HOT 2
- How to configure ObjectMapper? HOT 2
- @Type serialization HOT 2
- Document collection always throw error while using readCollections HOT 1
- Object with relations itself HOT 1
- @Relationship is not being deserialized HOT 2
- Creating a resource on the server - required id field HOT 2
- Does the library support Javas webclient and the reactor implementation? HOT 2
- "jsonapi": { "version": "1.0" } Parser HOT 2
- Get value above "attributes" level HOT 2
- Relationship attributes dont serialized HOT 3
- The library does not support JSON Specification "8.3 Inclusion of Related Resources" HOT 13
- Class doesn't have a Type annotation error, even though the class does have one HOT 3
- Proguard issues with jsonapi-converter when Android project to targets java 17 HOT 2
- InvalidJsonApiResourceException: Resource must contain at least one of 'data', 'error' or 'meta' nodes
- Handling local identifier ("lid") when creating resource HOT 4
- Backward compatibility HOT 2
- Pagination is not supported with decode fein in Java Spring boot HOT 2
- CVE-2023-0833 5.5 Generation of Error Message Containing Sensitive Information vulnerability with Medium severity found HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jsonapi-converter.