NHibernate custom SQL object creation

Question

Somewhat-simplified example situation: I have entities A and B which are incredibly "heavy" domain objects. Loading one from the database is a pretty big deal. Then I have an entity C, which is a very simple object that has a label string, one A, and one B -- both lazy.

I'm doing some low-level querying to create huge lists of C, so I know exactly what IDs I need to save for C.A and C.B, but I don't want to load up entire objects and set them to the properties, because the overhead is insane.

Instead, I want to just insert the IDs directly into my C entities, and then let the A and B properties on it be fully loaded later only if needed.

I see the <sql-insert/> tag in the documentation, but the section is really sparse.

Is there any way to do what I want to do inside the NHibernate framework, or should I just do raw SQL? I'm trying to keep database portability if possible, which makes me shy away from the raw option. Seems like there's got to be a better way I'm missing.

Answer 1

I don't know if NHibernate allows this (separate objects on same base data) but usually I make "digest" objects which can be upconverted into the full-blown objects (even with lazy loading on the full-blown objects). I usually do this with code-gen'd or manual ORM layers.

Large collections are usually of digests, and then if the properties or methods needed aren't exposed by the digest, they are upconverted into complete objects for the call, or to be passed etc.

Answer 2

Dan -- not sure if this will work without testing, but its worth a shot. I guess your already have the Ids that you want to add to your C -- so set your associations (many-to-one I'm assuming) to insert="false" and update="false" (maybe cascade="none" would work alternatively as well). Then create an "empty copy" of your A and B entities, add the Ids to them, add them to C and try to save C (Session.SaveOrUpdateCopy(C)). Hopefully NHibernate will not attempt to add a new A and B object into their respective table, but will simply set the correct Ids within the C table -- this way you don't have to load the A and B entities.

The bad part is, if you have to save or update A and B, you'll have to do it directly. The other bad part is that I don't have time to test this, so I don't know if it will work.