db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From e...@jpox.org
Subject Re: User demand and Issue 150. [was Re: Issue 150: Consistency requirements for relationships with mapped-by]
Date Fri, 30 Dec 2005 10:58:15 GMT
Quoting Craig L Russell <Craig.Russell@Sun.COM>:

> Hi Erik,
>
> For the record, the quoted lines are not mine. Credit where credit is
> due. The quoted lines are David Bullock's.
>

Oh, my apologies. Too much wine these days.

> More comments below.
>

They answer my question. Thanks.

> On Dec 29, 2005, at 3:41 PM, erik@jpox.org wrote:
>
> > Quoting Craig L Russell <Craig.Russell@Sun.COM>:
> >
> >>> public class Invoice {
> >>>   private Set<Line> lines;
> >>>   public void addLine(Line line) {
> >>>       this.lines.add(line);
> >>>   }
> >>> }
> >>>
> >>> public class Line {
> >>>   private Invoice invoice;
> >>>   public void setInvoice(Invoice invoice) {
> >>>     this.invoice = invoice;
> >>>   }
> >>> }
> >>>
> >>> and I do this:
> >>>
> >>> static {
> >>>  Invoice invoice = Util.getPersistentInvoice("1234");
> >>>  Line line = new Line();
> >>>
> >>>  line.setInvoice(invoice):
> >>>  invoice.addLine(line);   /*expensive?*/
> >>> }
> >>>
> >>> that the JDO impl necessarily fetches the entire contents of the
> >>> Invoice.lines collection?  And *because* of this problem, you as a
> >>> user wish to avoid the invoice.addLine(line) call?
> >>>
> >>> I guess there might be JDO impl's out there which do that.  But I'd
> >>> rather pay money for a good one [1] which allowed me to control the
> >>> fetch policy.  There's absolutely no reason why the JDO impl needs
> >>> to go to the database to let me invoke .add() on a SCO collection,
> >>> until it needs to flush and do an INSERT.\
> >
> > Remember the history about List.contains?
>
> I guess not.
>
> > Add, contains and many other
> > operations requires "(o==null ? e==null : o.equals(e))", in that
> > sense you have
> > to load all objects.
>
> I don't follow. Sidebar: the quoted section is from javadoc for
> java.util.Collection, which for the purposes of this discussion I've
> copied below. A correct implementation of java.util.List (or
> java.util.Collection, or any of the other supported collection types)
> will respond appropriately to all the methods in the interface. Some
> of the methods can be implemented to avoid loading the elements of
> the collection by translating the methods into equivalent back end
> datastore calls. If an implementation doesn't want to bother with the
> details, then it has the ability to transparently instantiate the
> collection and then run the user's method.
> >
> > JPOX, FYI, does not follow this rule and runs equality by comparing
> > the identity
> > columns of these objects (primary keys for FCO) or the values for
> > embedded
> > fields.
>
> This is fine. This is discussed in 5.4:
> Applications should implement equals for persistence-capable classes
> differently from Object’s default equals implementation, which simply
> uses the Java VM object identity. This is because the JVM object
> identity of a persistent instance cannot be guaranteed between
> PersistenceManagers and across space and time, except in very
> specific cases noted below.
> Additionally, if persistence instances are stored in the datastore
> and are queried using the == query operator, or are referred to by a
> persistent collection that enforces equality (Set, Map) then the
> implementation of equals should exactly match the JDO implementation
> of equality, using the primary key or ObjectId as the key. This
> policy is not enforced, but if it is not correctly implemented,
> semantics of standard collections and JDO collections may differ.
>
> Craig
>
> >
> >>>
> >>
> >> Craig Russell
> >
> java.util.Collections
> any methods in Collections Framework interfaces are defined in terms
> of the equals method. For example, the specification for the contains
> (Object o) method says: "returns true if and only if this collection
> contains at least one element e such that (o==null ? e==null :
> o.equals(e))." This specification should not be construed to imply
> that invoking Collection.contains with a non-null argument o will
> cause o.equals(e) to be invoked for any element e. Implementations
> are free to implement optimizations whereby the equals invocation is
> avoided, for example, by first comparing the hash codes of the two
> elements. (The Object.hashCode() specification guarantees that two
> objects with unequal hash codes cannot be equal.) More generally,
> implementations of the various Collections Framework interfaces are
> free to take advantage of the specified behavior of underlying Object
> methods wherever the implementor deems it appropriate.
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>




Mime
View raw message