Question

In legacy database tables we have numbered columns like C1, C2, C3, C100 or M1, M2, M3, M100.
This columns represent BLOB data.

It is not possible to change anything it this database.

By using JPA Embeddable we map all of the columns to single fields. And then during embedding we override names by using 100 override annotations.

Recently we have switched to Hibernate and I’ve found things like UserCollectionType and CompositeUserType. But I hadn’t found any use cases that are close to mine.

Is it possible to implement some user type by using Hibernate to be able to map a bundle of columns to a collection without additional querying?

Edit:
As you probably noticed the names of columns can differ from table to table. I want to create one type like “LegacyArray” with no need to specify all of the @Columns each time I use this type.
But instead I’d use

  @Type(type = "LegacyArrayUserType",
        parameters =
   {
      @Parameter(name = "prefix", value = "A"),
      @Parameter(name = "size", value = "128")
   })
   List<Integer> legacyA;

  @Type(type = "LegacyArrayUserType",
        parameters =
   {
      @Parameter(name = "prefix", value = "B"),
      @Parameter(name = "size", value = "64")
   })
   List<Integer> legacyB;

Answer 1

I can think of a couple of ways that I would do this.

1. Create views for the collection information that simulates a normalized table structure, and map it to Hibernate as a collection:

Assuming your existing table is called primaryentity, I would create a view that’s similar to the following:

-- untested SQL...
create view childentity as
(select primaryentity_id, c1 from primaryentity union
select primaryentity_id, c2 from primaryentity union
select primaryentity_id, c3 from primaryentity union
--...
select primaryentity_id, c100 from primaryentity)

Now from Hibernate’s perspective, childentity is just a normalized table that has a foreign key to primarykey. Mapping this should be pretty straight forward, and is covered here:

• http://docs.jboss.org/hibernate/stable/core/reference/en/html/collections.html

The benefits of this approach:

• From Hibernate’s point of view, the tables are normalized, it’s a fairly simple mapping
• No updates to your existing tables

The drawbacks:

• Data is read-only, I don’t think your view can be defined in an updatable manner (I could be wrong)
• Requires change to the database, you may need to create lots of views

Alternately, if your DBA won’t even let you add a view to the database, or if you need to perform updates:

---

2. Use Hibernate’s dynamic model mapping facility to map your C1, C2, C3 properties to a Map, and have some code you your DAO layer do the appropriate conversation between the Map and the Collection property:

I have never done this myself, but I believe Hibernate does allow you to map tables to HashMaps. I’m not sure how dynamically Hibernate allows you to do this (i.e., Can you get away with simply specifying the table name, and having Hibernate automatically map all the columns?), but it’s another way I can think of doing this.

If going with this approach though, be sure to use the data access object pattern, and ensure that the internal implementation (use of HashMaps) is hidden from the client code. Also be sure to check before writing to the database that the size of your collection does not exceed the number of available columns.

The benefits of this approach:

• No change to the database at all
• Data is updatable
• O/R Mapping is relatively simple

The drawbacks:

• Lots of plumbing in the DAO layer to map the appropriate types
• Uses experimental Hibernate features that may change in the future