Re: Better start with Wonder than WO
Re: Better start with Wonder than WO
- Subject: Re: Better start with Wonder than WO
- From: Mike Schrag <email@hidden>
- Date: Thu, 20 Mar 2008 21:41:50 -0400
What a vigourous debate this has ensued!
examples and build entire apps using
session().defaultEditingContext().
I never really have any troubles with EC locking -- you mean when
people make a new EC and forget to lock it?
Yes (which should be fairly often) and it's easy to not do properly if
you're using stock WO without any other libraries (like MultiECLock,
Wonder, or others). It's not just forgetting to lock it, it's not
knowing when to lock, or that you have to lock in various scenarios,
or accidentally leaving a lock open because you tried to unlock in the
wrong place. Classic sort of example is that you lock, fetch an eo
into a component ivar, unlock, then render your page which touches the
EO to display some properties of your object. Many people don't
realize that it's not enough to lock around your fetch or around your
save, but that almost anything that touches the EC stack should be
locked or you can get screwed. The problem is that leaving off a lock
doesn't fail, it all appears to work fine until you start getting
concurrency going and then things go to hell in crazy ways.
Deadlocking is the other fun random side-effect that everyone loves.
Any feature that you have to "be careful of" to me is a red flag.
You're a WO expert, so I don't expect this to be as much of a problem
for you. But for a huge number of people, it's a problem. Definitely
for beginners, it's one of the number one problems.
I now no longer care about inverse relationships -- Wonder does
that for me.
I saw that go through on a recent wonder build. It sounds good for
"small relationships" -- how does this get avoided in large
relationships?
(These are actually all optional features, off by default, btw)
It does it all the time when it's on. I'm of the opinion that you have
the relationships in your model, it should be addObjToBothSides all
the time. This is another one new people often don't realize or
understand -- that you can even have asymmetric relationship states.
Half-out-of-sync object graph is a NASTY bug to track down and new
people get totally tripped up by it. If the relationship is too big,
I personally don't believe you should model it as you don't probably
need it anyway. The only issue here is cascade delete rules, but for
my money, I'd rather have the normal case work properly (i.e. modeled
= in sync) and when you get to the point that you have enough data
where faulting the inverse is a problem, you likely also are at a
point in your WO career where you will better understand what it means
to remove the inverse relationship and implement the cascade delete
manually via, for instance, the willDelete method on
ERXGenericRecord. It would be nice for WO to make it so you can make
non-class relationships that cascade delete but do not trigger an
inverse fault. I understand that this actually USED to work many
versions ago, but I tried it a while back in earlier 5.x's and it was
no longer the case.
ms
_______________________________________________
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