Hi all,
I have a question rather then a problem. I am working on an application that has the general Order - Orderline relationship. However, every order can have zero or more invoices. These invoices have the same relationship with the orderlines as the Order do. For example I have an order with 10 orderlines. I have 2 invoices with each 5 orderlines.

Is this a valid approach to work with? How should my mapping file look, especially the cascade and inverse part?

I hope someone can help, because I cannot find an example and I do not know how to create a mapping like this.

greetz Jettro

Please post your table structures so that someone can provide the HBM XMLs.

Table order:
id (pk)
create_date
extra_costs
payed

Table orderline:
id (pk)
order_id (not null, fk)
invoice_id (fk)
product_id (not null,fk)
quantity
price

Table invoice:
id(pk)
payed

Table product:
id (pk)
name
price

As for the datatypes, don't care to much. Figure that out myself.

Thanks

I don't see anything non-standard in this structure. I'd use, apart from the trivial stuff like ids and pure properties:

in Order
set orderline inverse="true"

in OrderLine
many-to-one order
many-to-one invoice
many-to-one product

in Invoice
set orderline inverse="true"

in Product, optionally (if you want the bidirectional link)
set orderline inverse="true"

The last item, set orderline in Product, is mostly not done, because it would lead to a huge set in any Product object containing references to any orderline ever associated to it. Mostly, such a set isn't of much use, because no function will want to traverse the set, having to deal with all those many orderlines, but a database query would be used to retrieve exactly those orderlines for the product that are needed.

From your table structure, I conclude that an invoice may contain orderlines of arbitrary orders.

Cascades might be useful from order to orderline as well as from invoice to orderline.

Same holds for lazy="false". The back direction from orderlines to order and invoice, resp., should not be made lazy="false". Otherwise you risk to load most orders and invoices into memory at the first database read.

Now I feel really stupid, you are right when you said "an invoice can contain any orderline from any order". I left out the most important property, I guess, an invoice can only contain orderlines from the order the invoice belongs to. so I missed one property in the invoice table.

invoice
id
order_id
payed

Maybe I need to explain more of what I want. I want to be able to remove orderlines when saving an order. I also want to be able to update orderlines while updating an invoice. I understand I cannot delete an orderline if I allready created an Invoice for that order/orderline. The most important for me is to be able to update an orderline if I update an invoice. I think it must be something like:

order
set orderline inverse=true cascade=all-delete-orphan

invoice
set orderline inverse=true cascade=save-update

Thank you so far, I am not there just yet. So more help is very welcome.

Your questions touch several topics.

1. Data modeling of invoices

The most elegant way of enforcing that an invoice contains orderlines of only one order would be to model

order <-- 1:n --> invoice <-- 1:n --> orderline

This way, the database (and class) structure would enforce that each invoice contains orderlines from exactly one order. Introducing the order id as a foreign key in the invoice, as you suggest, doesn't keep anyone to attach orderlines from different orders to that invoice.

The reason, however, that this problem is mostly solved the way you suggest (it's a quite common problem in database oriented systems supporting business processes) is that, when entering an order and its orderlines into the system, most probably nothing is known yet about invoices. So orderlines are attached directly to orders, and the invoices are built up separately later on. You might add a database constraint that allows only proper orderlines attached to an invoice.

2. Deleting, updating etc.

The next design step to take is analyzing your business process and the functionality needed to support it. This should be in no way coupled to Hibernate's functionality. When can orderlines be attached to orders? ... to invoices? Does removing an orderline from an invoice also mean removing it from the order? That can only be answered from the view of your users and their business rules.

3. Cascading

Cascading doesn't add any new database manipulation features to Hibernate. It's just a way to reduce Hibernate calls for certain routine operation sequences, like updating a parent together with all its children. Therefore, when finished with step 2, I'd only introduce those cascading rules that are totally clear to me and that support operation sequences flowing from my business requirements. It's no shame to call a few save or delete operations explicitly instead of cascading.

Also remember that your Java application is totally responsible for maintaining the correct associations between objects. So, if you want to completely delete an orderline, you'll have to cut all associations off, not only from the order, but also from the invoice. Otherwise, Hibernate will scream at you that the object you want to delete from one side will be re-created from the other side.

That said, I don't see a problem with the cascading structure you suggest.

The last post does answer my question,

1. Hmm never thought about it that way, my application allready assured you could only add an invoice to the specific order and add only order lines from that order to the invoice.

2. Absolutely right, I agree with you all the way

3. This is where my problem was, I guess I allready have created the solution like you have suggested. And indeed I did recevie a lot of error message like you mentioned before I did all the manual stuff. I was just hoping there was I way to automate more of the saving and deleting.

Thank you all very much for your answers