Need help with Hibernate? Read this first:
http://www.hibernate.org/ForumMailingli ... AskForHelp

Hibernate version:
3.1.2

Name and version of the database you are using:
MySQL 5.0.18

I am implementing a retail site where products have addons and warranties. Addons and warranties are really products themselves. I have intermediate tables for addons and warranties with the parent product id and the child product id.

I have it working now so the parent product can access the child product ids in the intermediate table. However, I'd like to make it so that the bag of addons could be a bag of Products instead of a bag of Addons. It would save an extra query each time I load a Product and have to display addons. The same goes for warranties.

Does anyone have experience with this indirect parent/child paradigm that could help me see how to work this?

Thanks!

Sure. If there's a suitable discriminator column, this isn't too hard to do. There is some ugliness because the discriminator values get hardcoded into your mapping file a couple of times..

ProductImpl gets two subclasses, AddonImpl and WarrantyImpl. Assuming that the discriminator column is "ProductTypeID" and has values 'p', 'a' and 'w', the Product mapping gets two bags:You should write an event handler or at least a product-validation method that ensures that the user hasn't put any warranties into the addons bag, etc.

I think that would work except that for each product, there is a unique set of addons and warranties. So I couldn't do a general where condition on the bag because it would return *all* of the addons or warranties.

If there were a way to specify a foreign key for it or simply have a bag of products with a where condition that includes a variable that could be set. It seems like that would work, but I don't think the where clause for a hibernate collection mapping supports variables in the where clause.

I think I found a solution for my situation. I can use a one-to-one, or the many-to-one mapping with unique set to true, to map the addon or warranty back to the product table with its foreign key. So in order to reference the actual product, I've setup a unique many-to-one relationship with the class being the Product class and the column being the product id itself.

Thanks for the help - your train of thought got me thinking of how to do it for my app.

My previously mentioned solution involves still having objects of type addon or warranty in the code. I'm wondering if there is a way to do the "bag" mapping that would circumvent mapping the addon/warranty at all and instead just having a bag of the parent type - product.

Does anyone have any other suggestions for this?

Thanks!

Use a Product interface. It won't matter if a particular bag holds just WarrantyImpls or just AddonImpls, so long as both classes implement The Product interface.

How would this filter the addons and warranties by the specific product id though? I guess that's the real obstacle for me. When I call up a particular product, I need to to get the addons and warranties for that particular product id, which is done with the intermediate relationship tables.

Those join tables are simple two-column things like ProductId/WarrantyId, or ProductId/AddonId, right? Doesn't the "normal" bidirectional many-to-many do what you need? That's described in section 7.5.3. "many to many" of the ref docs.

Being fairly inexperienced with hibernate, I think that's a great idea. I have had to think through this a few times because this data is going to be completely refreshed every day. That means that every time I run it, I have to do two passes through the data - one to get all of the products, then another to save all of the addons and warranties because the surrogate product id will not necessarily have been created for the addon/warranty yet during the first pass.

I had been trying to do it with only one pass with various methods. If I knew hibernate better, I might be able to do that. It seems like the better way to do it is to make it fit better with the example that you're talking about. That makes the code simpler too. With some initial refactoring, it looks like it is going to work.

Thanks a lot for the help!