Re: User demand and Issue 150. [was Re: Issue 150: Consistency requirements for relationships with mapped-by]

[Craig L Russell]

Hi Erik, For the record, the quoted lines are not mine. Credit where credit is due. The quoted lines are David Bullock's. More comments below. On Dec 29, 2005, at 3:41 PM, [EMAIL PROTECTED] wrote: Quoting Craig L Russell <[EMAIL PROTECTED]>: 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature