I believe this fits my use case of intercepting the JSON:API response to do some processing on it :)
This message was deleted
Hi @remmeier I want to remove the foreign key constraint but to keep the relation between objects but without having a constraint
so If we have a parent object which has a list of childs
I want to easily link a non existent parent to a child object
this is can be done using jpa only in spring boot using this annotation @org.hibernate.annotations.ForeignKey(name = "none") but with crnk it returns like this when doing a post
"errors": [
{
"status": "404",
"code": "NOT_FOUND",
"detail": "type=parent, ids=[2972b858-8f77-4462-89bb-7a406e248f46]",
"source": {
"pointer": ""
},
"meta": {
"type": "NOT_FOUND",
"resourceType": "child"
}
}
]
}Parent class
@Data
@JsonApiResource(type = "parent", resourcePath = "parents")
@Entity
@Table(name = "parents")
public class Parent {
@Id
@JsonApiId
private UUID id;
private String name;
@JsonApiRelation(opposite = "parent",
lookUp = LookupIncludeBehavior.AUTOMATICALLY_WHEN_NULL,
repositoryBehavior = RelationshipRepositoryBehavior.FORWARD_OPPOSITE)
@OneToMany(mappedBy = "parent")
@org.hibernate.annotations.ForeignKey(name = "none")
private List<Child> childs;
}Child Class
@Data
@JsonApiResource(type = "child", resourcePath = "childs")
@Entity
@Table(name = "childs")
public class Child {
@Id
@JsonApiId
@GeneratedValue(generator = "UUID")
@GenericGenerator(name = "UUID", strategy = "org.hibernate.id.UUIDGenerator")
@Column(name = "id", updatable = false, nullable = false)
private UUID id;
@JsonApiRelationId
@Column(name = "parent_id")
private UUID parentId;
private String type;
@JsonApiRelation(idField = "parentId", opposite = "childs",
lookUp = LookupIncludeBehavior.AUTOMATICALLY_WHEN_NULL,
repositoryBehavior = RelationshipRepositoryBehavior.FORWARD_OWNER,
serialize = SerializeType.EAGER)
@ManyToOne(fetch = FetchType.EAGER)
@JoinColumn(name = "parent_id", insertable = false, updatable = false)
@org.hibernate.annotations.ForeignKey(name = "none")
private Parent parent;
public void setParentId(UUID parentId) {
this.parentId = parentId;
this.parent = null;
}
public void setParent(Parent parent) {
this.parent = parent;
this.parentId = parent != null ? parent.getId() : null;
}}
@rehab-reda0 Not the first time the topic has come up. As of yet there is no flag to ignore missing relationships. It will result in an error. Maybe @JsonApiRelation should allow to relax it. But generally not too fond of using it. An alternative approach could be if the parent repository returns a place holder with a status "DELETED" or something like that. Maybe could also be a visable option.
@SarangKanabargi there is an architecture chapter in the docs: http://www.crnk.io/releases/stable/documentation/#_architecture. Short answer is to model the business as a resource model. It requires a bit a different kind of thinking, but the end result can be a cleaner API.
I know this can be solved by using JPA Entity graphs, but no clue how to integrate this with CRNK
Just now not aware of an issue. But 2.11 is really old and it should be a more or less smoth upgrade path. The one thing that did change in the meantime is a larger relationship handling refactoring. e.g. the JpaRelationshipRepository (or something like that) does not exist anymore. So things got (much) simpler. But a profiler or something should tell you where the loading happens. Generally crnk will be the one processing the "include", not JPA. So you would get a query for every inclusion. But not 1+n, rather 1+1
per default it will not load the entity graph in jpa, as it this can be a shource of trouble in many more complex scenarios.
:)
this seems to activate it
I am building a custom HttpStatusBehavior to return a custom Http Status code based on the type of the resource which I am reading from HttpStatusContext in getStatus(). When sending a DELETE request the ResponseDocument in HttpStatusContext is null since no data is returned in the response. How do you suggest getting the type of the resource then please?
would be a little PR
One other question, when I enable entity graph within crnk by setting fetchRelations to true and I pass a OneToMany relation through the include query parameter
this makes the collection type also part of the entity graph which is really bad for performance (HHH000104: firstResult/maxResults specified with collection fetch; applying in memory!)
Is there anyway to trigger a subselect query for collection types? So kind of a hybrid solution using entity graphs for one-to-one and many-to-one relationships and for collections a new sub select query?
this makes the collection type also part of the entity graph which is really bad for performance (HHH000104: firstResult/maxResults specified with collection fetch; applying in memory!)
Is there anyway to trigger a subselect query for collection types? So kind of a hybrid solution using entity graphs for one-to-one and many-to-one relationships and for collections a new sub select query?
but all fetchPaths are passed through the EntityGraphBuilderImpl
@remmeier could you outline one of the use cases adding a TransactionRunner such as SpringTransactionRunner to a CRNK server instance solves? I understand the benefit if multiple actions are being performed behind a single call, however my understanding is only a single CRUD operation should be occurring. Is this for supporting multiple operation scenarios? Or are the single operations not as simple as they seem?
I dont like the answer, but general graph loading in JPA/Hibernate is sh*t. not sure about most recent versions. Usually things explode in doing too much in a single query and limited options to prevent it or giving weird behavior. in crnk the graph loading is more robust and also accounts for things like security. for that reason never tried to go much further in jpa. one crnk limtation as of yet, it will assemble the graph in the response,.not the mapstruct.objects. sometimes the later would also be desirable.
transaction runner has different use cases. if the create/update/delete is more complex spanning multiple queries. operationsmodule supporting bulk mutation. and if desired database isolation when doing multiple reads/graph loading. for the later read committed is a frequent default, so not much impacf here.
using @data notation on my entity's
this creates a hashCode method for all properties and this triggers many lazy load queries when it creates a TupleElement at a certain point:
TupleElement(Object[] data) {
this.data = data;
this.hashCode = Arrays.hashCode(data);
}
sometimes it is simpler to use entities and db views rather than DTOs
to simplify relationshift handling in JPA I often make use of JsonApiRelationId to avoid all the relationship loading stuff and be closer to the relational model. so each relationship has a primitive and a entity-based atteibute mapped to the same column.
the docs/demo should have an example
updates will then use the primitve field