Re: One to many not nullifying when reverse is not marked for in-class generation
Re: One to many not nullifying when reverse is not marked for in-class generation
- Subject: Re: One to many not nullifying when reverse is not marked for in-class generation
- From: Aaron Rosenzweig via Webobjects-dev <email@hidden>
- Date: Sun, 28 Jul 2019 18:08:11 -0400
Hi Robert,
Alright it’s coming together but let’s make it concrete. Let’s make a complete
story shall we?
“Employee” table has an FK to “Company”
“Company” has a conceptual “toMany” to “Employee.” You could model it, or not.
If you model it, you could make it visible, or not (class property). This is
the big part of the question, how to model this “convenience” relationship
since it isn’t real, it raises questions.
Given the above, we now delete a company object, what should happen?
If you model the “Company.employees” to-many relationship and make it a class
property you have a choice for the delete rule:
1) Deny - if it finds at least one employee, it refuses the delete of the
company
2) Nullify - it goes out to find all the 5,000 employees and suddenly breaks
their bond the company so that they are now without a job.
3) Cascade - it goes out and terminates, lethally, all 5,000 employees before
destroying the company.
I’m willing to bet, dollars to donuts, that 1/2/3 will be ignored if the
“employees” to-many relationship is not a class property. It’s gotta be visible
for it to do either of those things. That makes sense right? If the idea of
making it invisible is to not take the hit for faulting in 5k employee objects,
how could it possibly “nullify” (for example) without faulting them in? That’s
why it would HAVE to be a class property if you want it to do that bookkeeping.
Generally, you’d never delete a company unless you manually, through a clever
UI, allowed the user to re-home all the employees. In this story line, I would
not model the “Company.employees” to-many relationship at all. If I ever needed
that info, I would fetch “Employee.fetch(ec, Employee.COMPANY.is
<http://employee.company.is/>(appleComputer).” That way I’m taking the hit only
when it’s needed. I would also make a true FK constraint in the DB that would
prevent Apple from being deleted so long as there was at least one employee.
I realize your case is not Employee and Company… but any story that has so many
objects that you feel bad about modeling the to-many I’d feel the same about. I
wouldn’t want the deletion of the Company to automatically nullify the 5k
places. That said, it appears you need this… and for that the best course of
action would be either:
A) Manually fetch the Employee’s where their company relationship is equal to
the one you are about to delete. Nullify all their relationships to company.
Delete the company. Save changes. This will take a while if there is a plethora
of employees. Might need a long running task so that the app doesn’t timeout or
block other users.
B) Let SQL nullify the FK and then delete the company. This would be fast and
use little java memory. There are various helper methods to achieve this but
here is one: ERXEOAccesUtilities.updateRowsDescribedByQualifier()
A and B could be encapsulated in a method
“Company.takeCareOfDependentsThenDelete()” that you create on Company.
AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/>
e: email@hidden <mailto:email@hidden> t: (301) 956-2319
> On Jul 28, 2019, at 4:42 PM, Robert Hanviriyapunt <email@hidden>
> wrote:
>
> Ok the root problem is that deleting records is leaving bad foreign keys.
>
> The reason for the problem is that I made a decision long ago that in certain
> circumstances I would model to-one relationships with a “hidden” to-many
> reverse relationship, hopefully to help save memory or something. The
> “hiding” is done by turning off the “class property” on the reverse to-many
> relationship but keep the nullify rule. Now when I delete the to-one
> relationship destination EO, it does not nullify, leaving bad foreign keys.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden