I have a class representing a forum post with an optional image :


ImageOrFile is a class that holds the file name, byte[], ...

I'm trying to find the best mapping for this situation, knowing that :

* This is a base class, and I have different subclasses for different forums.
So, I would like to hard code as little table names as possible (I use XDoclet).

* It's quite important to use some kind of lazy loading as the attachement holds a byte[] that can be quite large. Further more, usually, the post title isn't uses in the same thread as the attachement's byte[] that is served by a separate Servlet.

I first thought about using something like
@hibernate.component prefix="attachement_" lazy="true"
The advantage is that I have everything in the same table, so I don't need to specify anything in the subclasses.
But for this to work, I need to run the bytecode instrumentation task. It seems that this bytecode instrumentation is quite a heavy process and the documentation is full of warnings that this it isn't recommended to use that "mostly marketing" feature.

So, the alternative seems to be using a one-to-one relation :
@hibernate.one-to-one constrained="true" outer-join="false" cascade="all"
But this has also some drawbacks too :
The attachement has to be an @hibernate.class, with it's own class and table.
This would mean that for each Post' subclass, I would also have to create an ImageOfFile subclass.
For a single class, this would be ok, but if the goal is to have many forums (so, many Post' subclasses), then it forces to make and maintain a lot of plumbing.

As I use many attachements in my applications, I have this problem quite often, and I would love to get the advises from more experimented Hibernate users.

Thanks you.

Sylvain.

After some more investigation, here is what I've found :

- bytecode instrumentation : Apart from the fact the I still couldn't run successfully the ant task, bytecode instrumentation seems to be ruled out for me :
Indeed, from this message : http://forum.hibernate.org/viewtopic.php?t=938730 (reply 7 &8), I understand that if you have some lazy properties (components) :
This is a real problem for me because part of the reason to have lazy properties/components is to spare memory as my lazy properties are byte[] of sometime big images. In a case where an entity holds several images in different properties, then the bytecode instrumentation is of no use because loading one image would imply loading all the component's images.

- one-to-one relation : This works, but you it has some drawbacks :
* The component must be an entity. So, for each Post' subclass, you have to create a new special purpose component entity with it's own table.

- hibernate collection with a composite-element :
The advantage here is that there is no need to create artifical entities for each Post' subclass.
But the drawbacks are :
* Still need to define a table for each Post' subclass.
* Even though this can be hidden by some more code, you need to manage a collection while you only need to have one object in the collection.

So, up to now, my choice goes to the last option : an hibernate collection with a composite-element.
Maybe there is a way with xdoclet to define the component's table by knowing the entity's table (like entity_table+"_images", ...). This would help reduce the plumbing in the subclasses when you have many, but I haven't found that yet.

Thanks for your comments / critics.

Sylvain.