db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bin Sun <sun2...@yahoo.com>
Subject Re: Issue 150: Consistency requirements for relationships with mapped-by
Date Fri, 23 Dec 2005 02:10:23 GMT
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 <db@dawnbreaks.net> 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. 

View raw message