1

Right now we have a JPA entity defined as:

@Entity
@Table(name="Foo")
public class Foo extends ParentClass {
...
}

Imagine that some Foo objects have been persisted in the database already. What would be the best way to programmatically change those persisted records to a sibling subclass of type Bar? 

@Entity
@Table(name="Bar")
public class Bar extends ParentClass {
...
}

We do not want to change the database schema, just the entity type of the already persisted Foo objects. I am hoping there is a better method than the only one I have thought of, which is manually grabbing the Foo objects, remapping to Bar, and re-persisting.

theblang
  • 10,215
  • 9
  • 69
  • 120

1 Answers1

1

Particularly I prefer to do it using pure SQL migration. In my company we use liquibase to version our database schema. So, to do the migration we just create changelogs for it.

Some argue that it's not the best solution, but I find it simple and quite powerful. In my opnion, for big projects it's the way to go.

EDIT:

Now that I see that you can't change the schema. I don't think this is possible in an easy way programmatically. You would need somekind of "TransformerService" between Foo and Bar, that simply copies the common parent fields, deletes the old Foo and persist the new Bar.

What I would do is to break the hierarchy and componentize ParentClass, so you can transfer only it between Foo and Bar, viceversa. This way you won't need to copy the fields or anything like that. It may need a lot of refactoring, but componentizing is better than creating big/complex hierarchies.

Or you can just run an SQL that changes the object directly at database. It's ugly, but it's the only way I see you could do something like that.

Caesar Ralf
  • 2,203
  • 1
  • 18
  • 36
  • We use `Liquibase` as well. The problem is that I don't want to change the schema. I want to be able to change a record from type `Foo` to type `Bar` (both of which inherit from `ParentClass`) programmatically. We want to allow the user to change the record type on the front-end. – theblang Jan 25 '13 at 18:57
  • 1
    I was afraid that I might have to do something like what you mentioned in your edit. Thanks for your input! – theblang Feb 28 '13 at 15:29
  • I would really appreciate your opinion on something regarding this. The people before me made a `Master` entity class with about 17 entity subclasses. They did this because those 17 entities, while having a majority of their data fields in common, did each have a unique field or two. Would it be better to just have one `Master` table with null values where appropriate? Inheritance seems awesome at first, until I need to do what was mentioned in the OP or when 17 joins happen because there are 17 tables in the database. – theblang May 31 '13 at 19:53
  • The problem with hierarchy is that your code becomes entagled with your parent class, disabling you to make changes without modifying everyone that inherits from it. It's good to remenber about Liskov Substition Principle: http://en.wikipedia.org/wiki/Liskov_substitution_principle A big table with lots of null is only useful if you are aiming for performance, but it's hard to maintain and upgrade. – Caesar Ralf May 31 '13 at 20:39
  • 1
    http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance?rq=1 – Caesar Ralf May 31 '13 at 20:43