I have a class which maps to a join table as a set. I also have another class which calls a stored procedure. The stored procedure is looking for the data in the join table. The problem is that Hibernate generates the sql for the join table after all other inserts, so the stored procedure gets called before the join table data is inserted.

Is there a way to force the inserts into the join table to occur first? I'm not sure why they happen at the end. In the mapping below, the treePathRollup points to a class which has a sql-insert that calls the stored procedure.

I'm using Hibernate 2.6 with Oracle 10

<subclass name="com.genuitec.hibernate.Style" discriminator-value="13">

<set name="StyleColors" table="REL_CTLG_ITM_T">
<key column="CTLG_ITM_1_ID" ></key>
<composite-element class="com.genuitec.hibernate.RelatedStyleColorAssoc">
<many-to-one name="styleColor" column="CTLG_ITM_2_ID"
not-null="true"
update="false"
class="com.genuitec.hibernate.StyleColor"/>
<property name="relCtlgItemId"
type="java.lang.Long"
not-null="true"
update="false"
column="REL_CTLG_ITM_ID"/>
<property name="createdUserId"
type="string"
not-null="true"
update="false"
column="CRT_USER_ID"/>

</composite-element>
</set>
<one-to-one name="treePathRollup" class="com.genuitec.hibernate.CtlgTreePathT" cascade="all" />
</subclass>

It makes no sense to insert to a join table before the two entity tables. The only way this would be possible is if the FKs from the join table to the entity tables were not real FKs and hence no constraints. That would be bad.

Can you flush the changes to the joined entities first, then execute the stored procedure last, rather than worrying about when the join table gets created?

Thanks for your reply. I agree that it wouldn't make sense to insert into the join table first, but I didn't explain my problem very well. I want the Style to be inserted first, then the Style's StyleColors set (the join table), and finally the Style's treePathRollup (stored procedure) to be called. I know that to Hibernate, the treePathRollup is part of the Style, which is probably why it gets called first.

Is there a way to tie the treePathRollup to the StyleColors set? I basically want it excecuted after the treePathRollup is created.

Thanks again!
Mike

Well I'm not sure I understand the relationship between a one-to-one property and a stored procedure, but maybe it's just a trigger that's firing? In any case, what I think will solve your problem is to not rely on the cascade to create the treePathRollup. Leave that property null (or turn off cascades). Once the main entity and the set are created, then flush(). After that, manually persist the treePathRollup and set its association to Style. You probably don't even need to manually persist it; just leave the association null and flush. Once that's done, then you can set the reference to the treePathRollup and finish (commit).

Does that make sense?

Exactly - I'm using the association as a way to trigger the stored procedure to get the post insert "batch work" done. Thanks for your suggestion. While technically this would work, I'm actually trying to make the updates driven from the mappings.

Is there a way to add some custom "meta data" to the mapping that my code could look for to determine if it should defer the flush until the main entity has been committed? Can I use the meta tag for this? If so, is there an api to retrieve it in my code?

Avoiding a totally workable solution just for the sake of "making the updates driven from the mappings" is a bit shortsighted IMHO. There is no construct to force the order of automatically generated SQL that I'm aware of. It does not and should not matter. If it does, you fall back to finer programmatic control, that's how frameworks behave.

I could make the case that utilizing a trigger in this manner is dangerous because it is not at all apparent to a maintainer what's happening when he reads the persistence code you're talking about writing. An explicit call to a stored proc would be much preferable for clarity and maintainability. A distant second would be an explicit persist call to the given associated entity.

-Chris

Chris,

All very good points. It's not that I'm intentionally ignoring your solution, but that I'm writing an application that needs to be generic. It would not know specifically about the treePathRollup, for example. I appreciate your advice and will just have to figure out how to determine, via the metadata, if there's a stored procedure call and issue that after an update. Thanks again.