tenwit wrote:
I don't know how to specify business keys in this scenario. There are two things you could try:
1) Change from <set> to <bag>. This works well if the tables are read-only, but you may run into efficiency problems if they're read-write and the collections can be large.
2) Omit all your fetch="join" attrbiutes, and go with the default fetch="select".
Approach 2 is okay. Actually, it is what I do in my first testing. However, if the collections are large, the efficiency is a problem.
In our project, we want to develop a BPM platform. Modeling the business entity is quite a challenge. Before we start, we decide to have enough testing of current ORM approach. Some testings are really extreme. Master-Detail-SubDetail structure is rather complex but an actual requirment for some application. Sometime the collection can be very large.
Well, lazy load can work. However, the bottleneck is not always in the database. We have tried fetching Master-Detail-SubDetail tables in a large database which has 1000'000 records. Using join syntax, it takes 2 second for MS SQL Server to generate results. This performance is allowable. In some cases, loading such a large dataset is useful, to do some complex calculation etc. Lazy load is this case seems lower the performance.
Thanks