I have a unique instance where I'd really like to use Hibernate 3.1's "not-found=ignore" attribute in my NHibernate app. It sounds like a mere convenience thing, and we could do some things w/ triggers to make things happy, but this would make life SO much easier.

Optionally, if anybody could suggest an alternative here, I'd be thrilled to have a suggestion or two.

We're writing some software to send bulk e-mails. We're collecting from a variety of sources, a list of "black-out" email addresses. People we've cut off of our distribution lists, people who have opted out, bounced e-mails, etc. Because of the nature of our system, an e-mail associated with a user is not GUARANTEED to be uniqe.

We're doing a query . . . a very complex query to decide who to send a bulk e-mail to.

It works fine. We have the HQL built and everything. Now, we'd like to take this bulk e-mail list and check to see if our users' e-mail addresses are in this blackout list . . . so I add to my HQL query the following sub-query . . .



or some such syntax. It times out. We turn off the timeout, and seriously . . . two and a half minutes with no return from the database. Otherwise, the query is quick as lightning.

What I'd LIKE to do is set this blackout info table up so it has a relationship to the user. Then I can do something in the query like


for when the user's email isn't on the blackout list.

I TRIED to do the following mapping . . .



And it seemed to work 'til I ran it through unit tests, and lo and behold . . . the 'Email' column always has a value which MAY OR MAY NOT be in the blackout list. So of course, I get the dreaded 'no object with the specified primary key' or something like that error.

Thus the wish for the not-found=ignore attribute.

Any suggestions would be greatly appreciated.

Thanks in advance.

-Falken

I have to map lots of legacy systems that have orphaned foreign keys. I posted a request for the not-found attribute in JIRA months ago, and would still LOVE to see it some time, as right now I can't map any relationships.

So, I did actually come up with a workaround to keep those orphaned foreign keys from blowing queries up and generally making your day nightmarish in the absence of the 'not-found' property.

Any class that you can't map a relationship to due to being a potential victim of an orphaned primary key, add the lazy='true' attribute to its mapping.

for example if you can't map parent.child because the child has been removed in some cases, change the child's mapping to . . .



Then put this method somewhere convenient . . .


Is this evil? VERY, VERY, VERY, VERY MUCH SO!! Not only are you potentially incurring overhead by throwing and catching an exception, then stifling it, and going on like nothing happened . . (I'm not a big fan of this usually) you're also making assumptions about why the .initialize call failed which may or may not be due to the FK being orphaned. Plus there may be other 'under the hood' reasons that I don't even know about which are problematic.

BUT!! ShouldBeNull(ChildClass obj) can help you to actually be able to map that heirarchy, and with some creative HQL, you can even avoid querying objects where the broken relationship could be a problem.

Again, that wonderful not-found attribute would be VERY nice