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: User demand and Issue 150. [was Re: Issue 150: Consistency requirements for relationships with mapped-by]
Date Fri, 30 Dec 2005 01:29:17 GMT
Hi, David!

    I think we should not be so captious on JDO. Each
behavior has a reason as we denote in the metadata.

    eg. Mark a class persistence capable, then we can
make an instance persistent in one thread and get it
by query in another thread. The metadata changed
program behavior without modifying the code.
The same for 'mapped by' metadata: mark a relation
bi-directional, and we can modify one side in one
thread and see the consistency in another thread. The
metadata changed program behavior without modifying
the code, too.

    As for the consistency problem before and after
commit, please note another option:
javax.jdo.option.IgnoreCache=true, this is quite
acceptable to developers and feasible to
implementations, while if we are rigid on JDO, we
shouldn't allow this feature since it breaks
consistency.

    Think back of the EJB-1.0 years, ideal design,
rigid rules, complex implementation details, all
result in poor performant products and low
acceptability in the market.

    BTW, I've read Craig's post and agree that this
consistency requirement be accross datastores since
it's a JDO feature.

--- David Bullock <db@dawnbreaks.net> wrote:

> Bin Sun wrote:
> 
> >Hi, David!
> >
> >    SCOCollection.add() may be implemented with
> lazy
> >feature, and you're right at this point. However,
> >convinience is also a concern for me. Since I had
> >noted the bi-directional attribute for a collection
> in
> >the metadata, I should be allowed to modify one
> side
> >of them and let the impl. do the last. As I said.
> >  
> >
> 
> Sure, and it would be a handy feature [1].  But
> since under the current 
> spec and its pending proposal, you don't get
> FULLY-managed 
> relationships, there is a span of time - between
> when you update one 
> side and when you finally commit - when the other
> side of the 
> relationship is NOT updated.  Does this partway
> solution meet any 
> programming need of yours?
> 
> To illustrate, using our Invoice and Line classes
> from before, under the 
> current and proposed specs, you are being offered
> the following behaviour:
> 
> static {
>   PersistenceManager pm = Util.aquirePM();
>   pm.currentTransaction().begin();
>   Invoice inv = Util.lookupInvoice(pm, "1234");  //
> only has 0 lines 
> when picked up.
>   Line line = new Line();
>   line.setInvoice(inv);  // we'll just update 1
> side, because section 
> 15.3 lets us take a shortcut
>   assert (inv.getLines().contains(line)); //
> assertion fails
>   pm.currentTransaction().commit();  // RetainValues
> or 
> DetachAllOnCommit are true.
>   assert (inv.getLines().contains(line)); //
> assertion succeeds
> }
> 
> Notice how the same assertion yields different
> results before and after 
> commit.  Is that really the behaviour you want of
> your 
> PersistenceManager?  I know you *really* want
> fully-managed 
> relationships, but since you can't have them, are
> you truly happy with 
> the above situation[2]?
> 
> sincerely,
> David.
> 
> 
> 
> [1] Although it only saves you one simple line of
> code.
> [2] As I hope I've made clear by now, I'm not happy
> with it, and I 
> regard this behaviour as obnoxious.  Nobody has so
> far presented any 
> argument at all as to why I should be happy with it.
> 



	
		
__________________________________ 
Yahoo! for Good - Make a difference this year. 
http://brand.yahoo.com/cybergivingweek2005/

Mime
View raw message