Question

I’m developing a RESTful webservice with spring-data as its data access layer, backed by JPA/Hibernate.
It is very common to have relationships between domain entities. For example, imagine an entity Product which has a Category entity.

Now, when the client POSTs a Product representation to a JAX-RS method. That method is annotated with @Transactional to wrap every repository operation in a transaction. Of course, the client only sends the id of an already existing Category, not the whole representation, just a reference (the foreign key).

In that method, if I do this:

entity = repository.save(entity);

the variable entity now has a Category with only the id field set. This didn’t surprise me. I wasn’t expecting a save (SQL insert) to retrieve information on related objects. But I need the whole Product object and related entities to be able to return to the user.

Then I did this:

entity = repository.save(entity);
entity = repository.findOne(entity.getId());

that is, retrieve the object after persisting it, within the same transaction/session.

To my surprise, the variable entity didn’t change anything. Actually, the database didn’t even get a single select query.
This is related with Hibernate’s cache. For some reason, when in the same transaction, a find does not retrieve the whole object graph if that object was previously persisted.

With Hibernate, the solution appears to be to use session.refresh(entity) (see this and this). Makes sense.

But how can I achieve this with spring data?

I would like to avoid to create repetitive custom repositories. I think that this functionality should be a part of spring data itslef (Some people already reported this in spring data’s forum: thread1, thread2).

Answer 1

tl;dr

References between entities in the web layer need to be made explicit by using links and should not be hidden behind semi-populated object instances. References in the persistence layer are represented by object references. So there should be a dedicated step transforming one (the link) into the other (the fully populated object reference).

Details

It’s an anti-pattern to hand around backend ids as such and assume the marshaling binding doing the right thing. So the clients should rather work with links and hand those to the server to indicate they want to establish a connection between an already existing resource and one about to be created.

So assuming you have the existing Category exposed via /categories/4711, you could post to your server:

POST /products
{ links : [ { rel : "category", href : "/categories/4711" } ],
  // further product data
}

The server would the instantiate a new Product instance, populate it with additional data and eventually populate the associations as follows:

1. Identify properties to be populated by looking up the link relation types (e.g. the category property here.
2. Extract the backend identifier from the given URI
3. Use the according repository to lookup the related entity instance
4. Set it on the root entity

So in your example boiling down to:

Product product = new Product();
// populate primitive properties
product.setCategory(categoryRepository.findOne(4711));
productRepository.save(product);

Simply posting something like this to the server:

POST /products
{ category : {
    id : 1, … },
  … 
}

is suboptimal for a lot of reasons:

1. You want the persistence provider to implicitly persist a Product instance and at the same time ‘recognize’ that the Category instance referred to (actually consisting of an id only) is not meant to be persisted but updated with the data of the already existing Category? That’s quite a bit of magic I’d argue.
2. You essentially impose the data structure you use to POST to the server to the persistence layer by expecting it to transparently deal with the way you decided to do POSTs. That’s not a responsibility of the persistence layer but the web layer. The whole purpose of a web layer is to mitigate between the characteristics of an HTTP based protocol using representations and links to a backend service.