ansaurus

Question

Answer 1

A:

When you say conversion you probably misrepresent the problem. What you really is trying to do in my opinion is to construct instance of one class based on an instance of the other class, for example:

public PayingUser(TrialUser theUser) {
...
}

Then you can delete old trial user and persist new paying user.

grigory 2009-04-13 17:24:27

Correct, but as I mentioned in the post, that would break all foreign key constraints. There are many tables referring to the TrialUser entity, including records of transactions, preferences, files, etc. All of these need to carry over to the PayingUser entity or the user would lose everything

rcampbell 2009-04-13 17:29:31

Sorry, I missed foreign keys. Or did you add them after I replied? Anyways, your copy constructor should copy relationships as well. It seems to be expensive so do not plan for this to happen more than once or twice during object lifetime.

grigory 2009-04-13 19:03:56

Answer 2

A:

Do you really need to represent the subscription level in the User type? Why don't you add a Subscription type in your system?

The relation would then be expressed as: a User has one Subscription. It could also be modeled as a one-to-many relationship if you wish to keep an history of subscriptions.

Then when you want to change the Subscription level of a User, instead of instantiating a new User you would create a new Subscription and assign it to a user.

// When you user signs up
User.setSubscription(new FreeSubscription());

// When he upgrades to a paying account
User.setSubscription(new PayingSubscription());

Is a TrialUser really that different from a PayingUser? Probably not. You would be better served with aggregation instead of inheritance.

The Subscription data can be stored in a separate table (mapped as an Entity) or it can be stored inside the Users table (mapped as a Component).

Patrick Lafleur 2009-04-14 19:18:46

I agree, but perhaps I picked a bad example. My real life situation is more complex: User superclass, Customer subclass which has FamilyHead, FamilyMember, Individual, Pro subclasses, etc. and Employee subclass with Staff, Admin, etc subclasses. They do have functionality I wouldn't want to extract

rcampbell 2009-04-16 13:28:05

Answer 3

+1 A:

The problem is more related to Java than anything else. You can't change a runtime type of an instance (at runtime), so hibernate does not provide for this kind of scenarios (unlike rails for example).

If you want to evict the user from the session, you'll have to evict associated entities. You have some choices:

Map the entity with evict=cascade (see the Session#evict javadoc)
Manually evict all associated entites (this can be cumbersome)
Clear the session, thus evicting all entities (of course, you'll lose the local session cache)

I've had a similar problem in grails, and my solution is similar to grigory's solution. I copy all instance fields, including the associated entities, then delete the old entity and write the new one. If you don't have that many relations this can be easy, but if your data model is complex you'll be better off using the native sql solution you described.

Here is the source, in case you're interested:

def convertToPacient = {
    withPerson(params.id) {person ->
      def pacient = new Pacient()
      pacient.properties = person.properties
      pacient.id = null
      pacient.processNumber = params.processNumber
      def ap = new Appointment(params)
      pacient.addToAppointments(ap);

      Person.withTransaction {tx ->
        if (pacient.validate() && !pacient.hasErrors()) {

          //to avoid the "Found two representations of same collection" error
          //pacient.attachments = new HashSet(person.attachments);
          //pacient.memberships = new HashSet(person.memberships);
          def groups = person?.memberships?.collect {m -> Group.get(m.group.id)}
          def attachs = []
          person.attachments.each {a ->
            def att = new Attachment()
            att.properties = a.properties
            attachs << att
          }

          //need an in in order to add the person to a group
          person.delete(flush: true)
          pacient.save(flush: true)
          groups.each {g -> pacient.addToGroup(g)};
          attachs.each {a -> pacient.addToAttachments(a)}
          //pacient.attachments.each {att -> att.id = null; att.version = null; att.person = pacient};

          if (!pacient.save()) {
            tx.setRollbackOnly()
            return
          }
        }
      }

Miguel Ping 2009-04-16 17:58:02

I really this this answer. First, I tried your 3rd option: clearing the session with EntityManager.clear(). This works. The problem is I'd lose any uncommited changes elsewhere in the persistence context. Now I'm tring the 1st suggestion with by adding @Cascade(value = CascadeType.EVICT) to the nested Entities causing the problem. This doesn't work, however, and I still get the same error (detached entity passed to persist). I'm putting the Hibernate tag on top of the JPA tag. This may be why.

rcampbell 2009-04-17 17:21:34

I also tried the 2nd option by passing the Session to the User object which would evict its child Entities, pass it to them so they could do the same, etc. down through the object graph. Nothing works. All three strategies end with the same error on the same child entity: "detached entity passed to persist"

rcampbell 2009-04-17 18:13:24

Answer 4

A:

So I finally figured out a working solution:

Ditch the EntityManager for updating DTYPE. This is mainly because Query.executeUpdate() must run within a transaction. You can try running it within the existing transaction, but that is probably tied to the same persistence context of the Entity you're modifying. What this means is that after you update DTYPE you have to find a way to evict() the Entity. The easy way is to call entityManager.clear() but this results in all sorts of side effects (read about it in the JPA spec). The better solution is to get the underlying delegate (in my case, a Hibernate Session) and call Session.evict(user). This will probably work on simple domain graphs, but mine were very complex. I was never able to get @Cascade(CascadeType.EVICT) to work correctly with my existing JPA annotations, like @OneToOne(cascade = CascadeType.ALL). I also tried manually passing my domain graph a Session and having each parent Entity evict its children. This also didn't work for unknown reasons.

I was left in a situation where only entityManager.clear() would work, but I couldn't accept the side effects. I then tried creating a separate Persistence Unit specifically for Entity conversions. I figured I could localize the clear() operation to only that PC in charge of conversions. I set up a new PC, a new corresponding EntityManagerFactory, a new Transaction Manager for it, and manually injecting this transaction manager into the Repository for manual wrapping of the executeUpdate() in a transaction corresponding to the proper PC. Here I have to say that I don't know enough about Spring/JPA container managed transactions, because it ended up being a nightmare trying to get the local/manual transaction for executeUpdate() to play nicely with the container managed transaction getting pulled in from the Service layer.

At this point I threw out everything and created this class:

@Transactional(propagation = Propagation.NOT_SUPPORTED)
public class JdbcUserConversionRepository implements UserConversionRepository {

@Resource
private UserService userService;

private JdbcTemplate jdbcTemplate;

@Override
@SuppressWarnings("unchecked")
public User convertUserType(final User user, final Class targetClass) {

  // Update the DTYPE
  jdbcTemplate.update("update user set user.DTYPE = ? where user.id = ?", new Object[] { targetClass.getSimpleName(), user.getId() });

  // Before we try to load our converted User back into the Persistence
  // Context, we need to remove them from the PC so the EntityManager
  // doesn't try to load the cached one in the PC. Keep in mind that all
  // of the child Entities of this User will remain in the PC. This would
  // normally cause a problem when the PC is flushed, throwing a detached
  // entity exception. In this specific case, we return a new User
  // reference which replaces the old one. This means if we just evict the
  // User, then remove all references to it, the PC will not be able to
  // drill down into the children and try to persist them.
  userService.evictUser(user);

  // Reload the converted User into the Persistence Context
  return userService.getUserById(user.getId());
 }

 public void setDataSource(final DataSource dataSource) {
  this.jdbcTemplate = new JdbcTemplate(dataSource);
 }
}

There are two important parts of this method which I believe make it work:

I've marked it with @Transactional(propagation = Propagation.NOT_SUPPORTED) which should suspend the container managed transaction coming in from the Service layer and allow the conversion to take place external of the PC.
Before trying to reload the converted Entity back into the PC, I evict the old copy currently stored in the PC with userService.evictUser(user);. The code for this is simply getting a Session instance and calling evict(user). See the comments in code for more details, but basically if we don't do this any calls to getUser will try to return the cached Entity still in the PC, except that it will throw an error about the type being different.

Though my initial tests have gone well, this solution may still have some problems. I will keep this updated as they are uncovered.

rcampbell 2009-04-18 15:47:17

Answer 5

A:

The problem is more related to Java than anything else. You can't change a runtime type of an instance (at runtime), so hibernate does not provide for this kind of scenarios (unlike rails for example).

I encountered this post because I am (or thought I was) having a similar problem. I've come to believe the problem is not with mechanics of changing types in the technology, but that evolving the types in general is not at all easy or straightforward. The issue is that types quite often have varying attributes. Unless you are mapping to different types only for behavioral differences, it isn't clear what to do with the additional information. For this reason, it makes sense to migrate types based on construction of new objects.

The problem is not 'related to Java'. it is related to type theory in general and more specifically object-relational mapping here. If your language supports typing, I'd love to hear how you can automatically change the type of an object at runtime and magically do something intelligent with the left over information. As long as we are spreading FUD: beware who you take advice from: Rails is a framework, Ruby is a language.

2009-06-08 23:10:10

ansaurus

tags:

views:

answers:

How to change Entity type in JPA?

related questions