Hi, David!
I'd like to share some of my ideas. We are
developing heavy stressed web applications based on
JDO. In each bi-di-relation, if the coder has to
assign both sides, the other side(usually a
collection) has to be loaded into memory and cause
much performance penalty. It's more efficient to leave
this synchronization task to the implementation.
This auto-sync behavior doesn't conflicts with the
data model because it's intended by specifying 'mapped
by' in the metadata.
Imagine a simple PC class 'Person', we can easily
do 'person.setIdcard(...)' in a tx, but if we specify
the 'idcard' field as primary-key in the metadata,
this invocation would fail. In this similar case, this
different behavior doesn't conflict with the data
model, because it's intended by specifying
'primary-key' in the metadata too.
You may say JDOUserException is a better choice,
but for the performance issues I mentioned, it's
better to leave sync-task to the implementation, at
least as a javax.jdo.option.
--- David Bullock <[EMAIL PROTECTED]> wrote:
> Craig L Russell wrote:
>
> > The "in your face" issue I'm wrestling with is the
> inconsistency in
> > the specification where we say that changes are
> ignored if made to the
> > "mapped-by" side and also that changes made to the
> memory model are
> > visible after commit.
> > [...]
> > It's evident to me that it's possible to detect
> changes to either side
> > of the relationship and make the two sides
> consistent.
> > [...]
> > I don't think that it makes sense for JDO that
> users' model changes to
> > be ignored just because they happen to be made to
> the "wrong side" of
> > the relationship.
> > [...]
> > 3. Inconsistencies should not be accepted, as they
> indicate user code
> > gone bad.
>
>
> We're mostly in vehement agreement, especially about
> not ignoring the
> user's assignments to fields. I think your proposal
> is certainly a
> clarification and improvement.
>
> It's just that I would include 'stupid user only
> updated one side of the
> relationship' as one of the inconsistencies that
> causes a
> JDOUserException to be thrown at commit. Instead of
> the JDO runtime
> 'fixing' the other side as a convenience. I don't
> want that
> convenience. If I've failed to update both sides of
> a relationship, that
> could easily have implications for the correctness
> of my code before
> commit, and I don't want JDO to silently fix things
> - I want to know.
>
> "Please force me to update both sides", is what I'm
> saying. I don't
> know who is demanding that users be allowed to only
> update one side of
> the relationship. Sure, I'd like that feature IF
> the update happened
> immediately as per managed relationships. But
> fixing my model after
> commit doesn't help me before commit, so you might
> as well make me do
> things manually (which is a coding obligation that I
> already have when
> not using persistence).
>
> So rather than new features I'm asking you to be
> more stringent!
>
> cheers,
> David.
>
>
> PS. The updated text is more clear, thanks.
>
__________________________________
Yahoo! for Good - Make a difference this year.
http://brand.yahoo.com/cybergivingweek2005/
