Wicket - Serialization of persisted and non-persisted JPA entities

Question

I know that when using Wicket with JPA frameworks it is not advisable to serialize entities that have already been persisted to the database (because of problems with lazy fields and to save space). In such cases we are supposed to use LoadableDetachableModel. But what about the following use-case?

Suppose we want to create a new entity (say, a Contract) which will consist, among other things, of persisted entities (say, a Client which is selected from a list of clients stored in the DB). The entity under creation is a model object of some Wicket component (say, a Wizard). In the end (when we finish our wizard) we save the new entity to the DB. So my question is: what is the best generic solution to the serialization problem of such model objects? We can't use LDM because the entity is not in the DB yet but we don't want our inner entities (like Client) to be serialized wholly, too.

My idea was to implement a custom wicket serializer that checks if the object is an entity and if it is persisted. If so, store only its id, otherwise use the default serialization. Similarly, when deserializing use the stored id and get the entity from the DB or deserialize using the default mechanism. Not sure, though, how to do that in a generic way. My next thought was that if we can do it, then we do not need any LDM anymore, we can just store all our entities in simple org.apache.wicket.model.Model models and our serialization logic will take care of them, right?

Here's some code:

  @Entity
  Client {
     String clientName;

     @ManyToOne(fetch = FetchType.LAZY)
     ClientGroup group;
  }

  @Entity
  Contract {
     Date date;

     @ManyToOne(fetch = FetchType.LAZY)
     Client client;
  }

  ContractWizard extends Wizard {
     ContractWizard(String markupId, IModel<Contract> model) {
        super(markupId);
        setDefaultModel(model);
     }
  }

  Contract contract = DAO.createEntity(Contract.class);
  ContractWizard wizard = new ContractWizard("wizard", ?); 

How to pass the contract? If we just say Model.of(contract) the whole contract will be serialized along with inner client (and it can be big), moreover if we access contract.client.group after deserialization we can bump into the problem: https://en.wikibooks.org/wiki/Java_Persistence/Relationships#Serialization.2C_and_Detaching

So I wonder how people go about solving such issues, I'm sure it's a fairly common problem.

Answer 1

I guess there are 2 approaches to your problem:

a.) Only save the stuff the user actually sees in Models. In your example that might be "contractStartDate", "contractEndDate", List of clientIds. That's the main approach if you don't want your DatabaseObjects in your view.

b.) Write your own LoadableDetachableModel and make sure you only serialize transient objects. For example like: (assuming that any negative id is not saved to the database)

public class MyLoadableDetachableModel extends LoadableDetachableModel {

private Object myObject;

private Integer id;

public MyLoadableDetachableModel(Object myObject) {
    this.myObject = myObject;
    this.id = myObject.getId();
}

@Override
protected Object load() {
    if (id < 0) {
        return myObject;
    }

    return myObjectDao.getMyObjectById(id);
}

@Override
protected void onDetach() {
    super.onDetach();
    id = myObject.getId();

    if (id >= 0) {
        myObject = null;
    }
}
}

The downfall of this is that you'll have to make your DatabaseObjects Serializable which is not really ideal and can lead to all kind of problems. You would also need to decouple the references to other entities from the transient object by using a ListModel.

Having worked with both approaches I personally prefer the first. From my expierence the whole injecting dao objects into wicket can lead to disaster. :) I would only use this in view-only projects that aren't too big.

Answer 2

Most projects I know of just accept serializing referenced entities (e.g. your Clients) along with the edited entity (Contract).

Using conversations (keeping a Hibernate/JPA session open over several requests) is a nice alternative for applications with complex entity relations: The Hibernate session and its entities is kept separate from the page and is never serialized. The component just keeps an identifier to fetch its conversation.