[jira] Commented: (JDO-267) Query with alias result generates incorrect SQL
[
http://issues.apache.org/jira/browse/JDO-267?page=comments#action_12361314 ]
Andy Jefferson commented on JDO-267:
Any clue as to which TCK test this refers to ? The test class name would be
nice.
> Query with alias result generates incorrect SQL
> ---
>
> Key: JDO-267
> URL: http://issues.apache.org/jira/browse/JDO-267
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Craig Russell
> Assignee: Andy Jefferson
>
> This JDOQL query results in the wrong SQL:
> /*UNIQUE*/ Boolean.FALSE,
> /*RESULT*/ "firstname AS firstName, lastname AS lastName",
> /*INTO*/FullName.class,
> /*FROM*/FullTimeEmployee.class,
> /*EXCLUDE*/ Boolean.TRUE,
> /*WHERE*/ "salary > 1000 & projects.contains(p) & " +
> "p.budget > limit",
> /*VARIABLES*/ "Project p",
> /*PARAMETERS*/ "BigDecimal limit",
> /*IMPORTS*/ "import org.apache.jdo.tck.pc.company.Project; " +
> "import java.math.BigDecimal",
> /*GROUP BY*/"firstname, lastname HAVING
> lastname.startsWith('emp')",
> /*ORDER BY*/"lastname ASCENDING",
> /*FROM*/0,
> /*TO*/ 3)
> 001 error: javax.jdo.JDODataStoreException: Error executing JDOQL query
> "SELECT DISTINCT THIS.FIRSTNAME AS firstName,THIS.LASTNAME AS
> lastName,THIS.LASTNAME FROM datastoreidentity0.PERSONS THIS INNER JOIN
> datastoreidentity0.PROJECT_MEMBER THIS_PROJECTS ON THIS_PROJECTS."MEMBER" =
> THIS.DATASTORE_IDENTITY INNER JOIN datastoreidentity0.PROJECTS UNBOUND_P ON
> UNBOUND_P.DATASTORE_IDENTITY = THIS_PROJECTS.PROJID LEFT OUTER JOIN
> datastoreidentity0.PROJECTS UNBOUND_P_BUDGET ON UNBOUND_P.DATASTORE_IDENTITY
> = UNBOUND_P_BUDGET.DATASTORE_IDENTITY WHERE THIS.DISCRIMINATOR = ? AND
> THIS.SALARY > 1000 AND UNBOUND_P_BUDGET.BUDGET > .2E4 GROUP BY
> THIS.FIRSTNAME,THIS.LASTNAME HAVING LOCATE(?,THIS.LASTNAME) = 1 ORDER BY
> THIS.LASTNAME" : Column name 'LASTNAME' appears more than once in the result
> of the query expression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (JDO-72) Test api.persistencemanager.OptimisticFailure hangs
[ http://issues.apache.org/jira/browse/JDO-72?page=all ]
Andy Jefferson resolved JDO-72:
---
Resolution: Fixed
Assign To: Andy Jefferson (was: Erik Bengtson)
Fixed in JPOX CVS - builds dated 29/12/2005 or later.
Now returns 3 nested exceptions, and the test passes :-)
> Test api.persistencemanager.OptimisticFailure hangs
> ---
>
> Key: JDO-72
> URL: http://issues.apache.org/jira/browse/JDO-72
> Project: JDO
> Type: Bug
> Components: tck20
> Environment: JPOX, Derby
> Reporter: Craig Russell
> Assignee: Andy Jefferson
>
> This test is designed to create conflicts in the database from two different
> JDO transactions. The changes in the cache must not be visible in the
> datastore or timeouts will occur. The exception here occurs when the second
> optimistic JDO transaction attempts to read a row that has been changed in
> the cache by the first optimistic JDO transaction.
> private void runTestOptimistic(PersistenceManager pm1,
>PersistenceManager pm2,
>PersistenceManager pm3) {
> if (!isOptimisticSupported()) {
>if (debug)
>logger.debug("OptimisticFailure tests not run; Optimistic not
> supported");
>return;
> }
> Transaction tx1 = pm1.currentTransaction();
> Transaction tx2 = pm2.currentTransaction();
> Transaction tx3 = pm3.currentTransaction();
> try {
>tx1.setOptimistic(true);
>tx2.setOptimistic(true);
>
>// create four instances to test
>tx1.begin();
>pm1.makePersistent(p1);
>pm1.makePersistent(p2);
>pm1.makePersistent(p3);
>pm1.makePersistent(p4);
>pm1.makePersistent(p5);
>p1oid = pm1.getObjectId(p1);
>p2oid = pm1.getObjectId(p2);
>p3oid = pm1.getObjectId(p3);
>p4oid = pm1.getObjectId(p4);
>p5oid = pm1.getObjectId(p5);
>tx1.commit();
>
>// update/delete the instances in tx1
>tx1.begin();
>PCPoint p1tx1 = (PCPoint)pm1.getObjectById(p1oid, true);
>PCPoint p2tx1 = (PCPoint)pm1.getObjectById(p2oid, true);
>PCPoint p3tx1 = (PCPoint)pm1.getObjectById(p3oid, true);
>PCPoint p4tx1 = (PCPoint)pm1.getObjectById(p4oid, true);
>p1tx1.setX(101);
>p2tx1.setX(201);
>pm1.deletePersistent(p3tx1);
>pm1.deletePersistent(p4tx1);
>
>// update/delete the instances in tx2
>tx2.begin();
> *** PCPoint p1tx2 = (PCPoint)pm2.getObjectById(p1oid, true); *** this is
> where the test hangs ***
>PCPoint p2tx2 = (PCPoint)pm2.getObjectById(p2oid, true);
>PCPoint p3tx2 = (PCPoint)pm2.getObjectById(p3oid, true);
>PCPoint p4tx2 = (PCPoint)pm2.getObjectById(p4oid, true);
>PCPoint p5tx2 = (PCPoint)pm2.getObjectById(p5oid, true);
>p1tx2.setX(102);
> // pm2.deletePersistent(p2tx2); // this should fail but succeeds
> due to an RI bug
>p3tx2.setX(202);
>pm2.deletePersistent(p4tx2);
>p5tx2.setX(502); // this change should not be committed
>Set expectedFailedObjects = new HashSet();
>expectedFailedObjects.add(p1tx2);
> // expectedFailedObjects.add(p2tx2);
>expectedFailedObjects.add(p3tx2);
>expectedFailedObjects.add(p4tx2);
>
>// commit tx1 (should succeed)
>tx1.commit();
>tx1 = null;
>
>// commit tx2 (should fail)
>try {
>tx2.commit();
>fail(ASSERTION_FAILED, "concurrent commit not detected");
>}
>catch (JDOOptimisticVerificationException ex) {
>// verify the correct information in the exception
> RUN OptimisticFailure.test[INFO] tck - Exception during setUp or runtest:
> PCPOINT.X,PCPOINT.Y,PCPOINT.ID FROM PCPOINT WHERE (PCPOINT.ID = ?)
> [java] NestedThrowables:
> [java] SQL Exception: A lock could not be obtained within the time
> requested>javax.jdo.JDODataStoreException: Fetch request failed: SELECT
> PCPOINT.X,PCPOINT.Y,PCPOINT.ID FROM PCPOINT WHERE (PCPOINT.ID = ?)
> [java] at
> org.jpox.store.rdbms.request.FetchRequest.execute(FetchRequest.java:195)
> [java] at
> org.jpox.store.rdbms.table.ClassTable.fetch(ClassTable.java:1739)
> [java] at org.jpox.store.StoreManager.fetch(StoreManager.java:665)
> [java] at
> org.jpox.state.StateManagerImpl.loadDFGFields(StateManagerImpl.java:1573)
> [java] at
> org.jpox.state.StateManagerImpl.loadDefaultFetchGroup(StateManagerImpl.java:1666)
> [java]
Re: InstanceLifecycleListener on detached instances
Craig, A callback called when a detached instance is changed. (gets dirty) Regards, Quoting Craig L Russell <[EMAIL PROTECTED]>: > Hi Erik, > > JDO 2 did not define any additional instance lifecycle callbacks, so > there are none for JDO 2 features. > > The dirty callback is executed during a lifecycle change from clean > to dirty, so it's not really suitable. > > What problem are you trying to solve? > > Craig > > On Dec 22, 2005, at 11:36 AM, [EMAIL PROTECTED] wrote: > > > Hi, > > > > Instance lifecycle listeners are only invoked if a PM is involved, > > but for > > detached instances none are called. The dirty listener is one that > > IMO could be > > called for detached instances. It means during detachment, a Dirty > > listener is > > assigned from the attached to the detached instance. > > > > Any thoughts? > > 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! > >
[jira] Resolved: (JDO-267) Query with alias result generates incorrect SQL
[ http://issues.apache.org/jira/browse/JDO-267?page=all ]
Andy Jefferson resolved JDO-267:
Resolution: Fixed
Presuming you're talking about SingleString test.
Now fixed in JPOX CVS - build dated 29/12/2005 or later.
> Query with alias result generates incorrect SQL
> ---
>
> Key: JDO-267
> URL: http://issues.apache.org/jira/browse/JDO-267
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Craig Russell
> Assignee: Andy Jefferson
>
> This JDOQL query results in the wrong SQL:
> /*UNIQUE*/ Boolean.FALSE,
> /*RESULT*/ "firstname AS firstName, lastname AS lastName",
> /*INTO*/FullName.class,
> /*FROM*/FullTimeEmployee.class,
> /*EXCLUDE*/ Boolean.TRUE,
> /*WHERE*/ "salary > 1000 & projects.contains(p) & " +
> "p.budget > limit",
> /*VARIABLES*/ "Project p",
> /*PARAMETERS*/ "BigDecimal limit",
> /*IMPORTS*/ "import org.apache.jdo.tck.pc.company.Project; " +
> "import java.math.BigDecimal",
> /*GROUP BY*/"firstname, lastname HAVING
> lastname.startsWith('emp')",
> /*ORDER BY*/"lastname ASCENDING",
> /*FROM*/0,
> /*TO*/ 3)
> 001 error: javax.jdo.JDODataStoreException: Error executing JDOQL query
> "SELECT DISTINCT THIS.FIRSTNAME AS firstName,THIS.LASTNAME AS
> lastName,THIS.LASTNAME FROM datastoreidentity0.PERSONS THIS INNER JOIN
> datastoreidentity0.PROJECT_MEMBER THIS_PROJECTS ON THIS_PROJECTS."MEMBER" =
> THIS.DATASTORE_IDENTITY INNER JOIN datastoreidentity0.PROJECTS UNBOUND_P ON
> UNBOUND_P.DATASTORE_IDENTITY = THIS_PROJECTS.PROJID LEFT OUTER JOIN
> datastoreidentity0.PROJECTS UNBOUND_P_BUDGET ON UNBOUND_P.DATASTORE_IDENTITY
> = UNBOUND_P_BUDGET.DATASTORE_IDENTITY WHERE THIS.DISCRIMINATOR = ? AND
> THIS.SALARY > 1000 AND UNBOUND_P_BUDGET.BUDGET > .2E4 GROUP BY
> THIS.FIRSTNAME,THIS.LASTNAME HAVING LOCATE(?,THIS.LASTNAME) = 1 ORDER BY
> THIS.LASTNAME" : Column name 'LASTNAME' appears more than once in the result
> of the query expression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Fwd: Apache JIRA : error thrown when resolving issue
On Tue, Dec 27, 2005 at 09:23:14PM -0800, Craig L Russell wrote: > Hi, > > Can someone in infra please help here? The reporting of issues seems > to be done broke. Fixed (manually reindexed). I'll do some more digging to find out what went wrong with the issue update. It looks like it failed before it could update the Lucene index. --Jeff > Thanks, > > Craig > > Begin forwarded message: > > > From: Andy Jefferson <[EMAIL PROTECTED]> > > Date: December 27, 2005 12:30:59 PM PST > > To: jdo-dev@db.apache.org > > Subject: Apache JIRA : error thrown when resolving issue > > Reply-To: jdo-dev@db.apache.org > > > > Hi, > > > > I tried to resolve issue JDO-220. It came back as "Error". Nice and > > informative message :-). I reopened it and tried again. It did the > > same. > > > > Now, if I look at > > http://issues.apache.org/jira/browse/JDO-220 > > it shows as Resolved. > > > > yet if I look at > > http://issues.apache.org/jira/secure/IssueNavigator.jspa? > > assigneeSelect=specificuser&sorter/ > > field=priority&mode=hide&reset=true&resolution=-1&assignee=andy&pid=10 > > 630&sorter/order=DESC > > it shows as Unresolved. > > > > > > Anyone with suitable supernatural powers want to try to convince > > JIRA that > > this issue is no longer of any interest and that JIRA should at > > least try to > > perform operations that people ask it to do ? > > > > -- > > Andy > > 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! >
[jira] Created: (JDO-268) org.apache.jdo.tck.api.instancecallbacks.InstanceLifecycleListenerAttach fails with new definition of makePersistent instead of attachCopy
org.apache.jdo.tck.api.instancecallbacks.InstanceLifecycleListenerAttach fails with new definition of makePersistent instead of attachCopy -- Key: JDO-268 URL: http://issues.apache.org/jira/browse/JDO-268 Project: JDO Type: Bug Components: tck20 Reporter: Craig Russell Assigned to: Andy Jefferson The PersistenceManager method attachCopy was replaced by makePersistent. The test case now fails. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Apache JIRA : error thrown when resolving issue
Thanks! Seems to be fixed now.CraigOn Dec 27, 2005, at 11:07 PM, Jeff Turner wrote:On Tue, Dec 27, 2005 at 09:23:14PM -0800, Craig L Russell wrote: Hi,Can someone in infra please help here? The reporting of issues seems to be done broke. Fixed (manually reindexed). I'll do some more digging to find out whatwent wrong with the issue update. It looks like it failed before it couldupdate the Lucene index.--Jeff Thanks,CraigBegin forwarded message: From: Andy Jefferson <[EMAIL PROTECTED]>Date: December 27, 2005 12:30:59 PM PSTTo: jdo-dev@db.apache.orgSubject: Apache JIRA : error thrown when resolving issueReply-To: jdo-dev@db.apache.orgHi,I tried to resolve issue JDO-220. It came back as "Error". Nice andinformative message :-). I reopened it and tried again. It did the same.Now, if I look athttp://issues.apache.org/jira/browse/JDO-220it shows as Resolved.yet if I look athttp://issues.apache.org/jira/secure/IssueNavigator.jspa? assigneeSelect=specificuser&sorter/ field=priority&mode=hide&reset=true&resolution=-1&assignee=andy&pid=10 630&sorter/order=DESCit shows as Unresolved.Anyone with suitable supernatural powers want to try to convince JIRA thatthis issue is no longer of any interest and that JIRA should at least try toperform operations that people ask it to do ?-- Andy Craig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/jdo408 276-5638 mailto:[EMAIL PROTECTED]P.S. A good JDO? O, Gasp! 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
[jira] Commented: (JDO-267) Query with alias result generates incorrect SQL
[
http://issues.apache.org/jira/browse/JDO-267?page=comments#action_12361329 ]
Craig Russell commented on JDO-267:
---
Sorry, I should have included the full stack trace and identified the test
case.
I decided to open a new JIRA for this issue because the JIRA that had been
tracking this test case had changed so many times the original description was
no longer descriptive.
Anyway thanks for the comment.
> Query with alias result generates incorrect SQL
> ---
>
> Key: JDO-267
> URL: http://issues.apache.org/jira/browse/JDO-267
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Craig Russell
> Assignee: Andy Jefferson
>
> This JDOQL query results in the wrong SQL:
> /*UNIQUE*/ Boolean.FALSE,
> /*RESULT*/ "firstname AS firstName, lastname AS lastName",
> /*INTO*/FullName.class,
> /*FROM*/FullTimeEmployee.class,
> /*EXCLUDE*/ Boolean.TRUE,
> /*WHERE*/ "salary > 1000 & projects.contains(p) & " +
> "p.budget > limit",
> /*VARIABLES*/ "Project p",
> /*PARAMETERS*/ "BigDecimal limit",
> /*IMPORTS*/ "import org.apache.jdo.tck.pc.company.Project; " +
> "import java.math.BigDecimal",
> /*GROUP BY*/"firstname, lastname HAVING
> lastname.startsWith('emp')",
> /*ORDER BY*/"lastname ASCENDING",
> /*FROM*/0,
> /*TO*/ 3)
> 001 error: javax.jdo.JDODataStoreException: Error executing JDOQL query
> "SELECT DISTINCT THIS.FIRSTNAME AS firstName,THIS.LASTNAME AS
> lastName,THIS.LASTNAME FROM datastoreidentity0.PERSONS THIS INNER JOIN
> datastoreidentity0.PROJECT_MEMBER THIS_PROJECTS ON THIS_PROJECTS."MEMBER" =
> THIS.DATASTORE_IDENTITY INNER JOIN datastoreidentity0.PROJECTS UNBOUND_P ON
> UNBOUND_P.DATASTORE_IDENTITY = THIS_PROJECTS.PROJID LEFT OUTER JOIN
> datastoreidentity0.PROJECTS UNBOUND_P_BUDGET ON UNBOUND_P.DATASTORE_IDENTITY
> = UNBOUND_P_BUDGET.DATASTORE_IDENTITY WHERE THIS.DISCRIMINATOR = ? AND
> THIS.SALARY > 1000 AND UNBOUND_P_BUDGET.BUDGET > .2E4 GROUP BY
> THIS.FIRSTNAME,THIS.LASTNAME HAVING LOCATE(?,THIS.LASTNAME) = 1 ORDER BY
> THIS.LASTNAME" : Column name 'LASTNAME' appears more than once in the result
> of the query expression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JDO-268) org.apache.jdo.tck.api.instancecallbacks.InstanceLifecycleListenerAttach fails with new definition of makePersistent instead of attachCopy
[ http://issues.apache.org/jira/browse/JDO-268?page=comments#action_12361330 ] Craig Russell commented on JDO-268: --- The behavior of makePersistent should be the same as attachCopy in the case of the parameter being a detached instance. This is the only test case for the attach behavior, pending new test cases being written. > org.apache.jdo.tck.api.instancecallbacks.InstanceLifecycleListenerAttach > fails with new definition of makePersistent instead of attachCopy > -- > > Key: JDO-268 > URL: http://issues.apache.org/jira/browse/JDO-268 > Project: JDO > Type: Bug > Components: tck20 > Reporter: Craig Russell > Assignee: Andy Jefferson > > The PersistenceManager method attachCopy was replaced by makePersistent. The > test case now fails. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Issue 152: Redundant IMPORTS keyword
Provided that we could use "import" or "IMPORT", that would be fine. An alternative, although not so compatible between the API and string versions, is to support the keyword "import" followed by a comma-separated, semicolon-terminated list of imports: SELECT UNIQUE firstname, lastname INTO FullName FROM Employee WHERE salary > 1000 && projects.contains(p) && p.budget > 3 VARIABLES Project p IMPORT org.apache.jdo.tck.query.result.classes.FullName, org.apache.jdo.tck.pc.company.Person, org.apache.jdo.tck.pc.company.Project; If we updated the spec (14.6.4) to allow this comma-separated, semicolon-terminated list in addition to the initial syntax, I think it would be intuitive: 14.6.4 Import statements The import statements follow the Java syntax for import statements. Import on demand is supported. Additionally, import statements may be expressed as a comma-separated, semicolon-terminated list of elements. For example, both import org.example.Foo; import org.example.Bar; import org.example.util.*; and import org.example.Foo, org.example.Bar, org.example.util.*; would be supported. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 27, 2005 7:01 PM To: JDO Expert Group; Apache JDO project Subject: Issue 152: Redundant IMPORTS keyword Javadogs, The keyword IMPORTS seems to be redundant. It introduces a series of statements each of which begins "import ...;". The keyword import could stand alone without the introductory IMPORTS. I think it would be better if we omitted the IMPORTS keyword entirely, so e.g. instead of: SELECT UNIQUE firstname, lastname INTO FullName FROM Employee WHERE salary > 1000 && projects.contains(p) && p.budget > 3 VARIABLES Project p IMPORTS import org.apache.jdo.tck.query.result.classes.FullName; import org.apache.jdo.tck.pc.company.Person import org.apache.jdo.tck.pc.company.Project; we would have: SELECT UNIQUE firstname, lastname INTO FullName FROM Employee WHERE salary > 1000 && projects.contains(p) && p.budget > 3 VARIABLES Project p import org.apache.jdo.tck.query.result.classes.FullName; import org.apache.jdo.tck.pc.company.Person import org.apache.jdo.tck.pc.company.Project; Craig 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!
Re: InstanceLifecycleListener on detached instances
Hi Erik,Ah. I missed the context earlier. I don't see any technical issues.My biggest concern is that it's getting late in the cycle to add new features.What do other experts think? Is it worthwhile to open the spec for this?CraigOn Dec 28, 2005, at 2:58 AM, [EMAIL PROTECTED] wrote:Craig,A callback called when a detached instance is changed. (gets dirty)Regards,Quoting Craig L Russell <[EMAIL PROTECTED]>: Hi Erik,JDO 2 did not define any additional instance lifecycle callbacks, sothere are none for JDO 2 features.The dirty callback is executed during a lifecycle change from cleanto dirty, so it's not really suitable.What problem are you trying to solve?CraigOn Dec 22, 2005, at 11:36 AM, [EMAIL PROTECTED] wrote: Hi,Instance lifecycle listeners are only invoked if a PM is involved,but fordetached instances none are called. The dirty listener is one thatIMO could becalled for detached instances. It means during detachment, a Dirtylistener isassigned from the attached to the detached instance.Any thoughts? Craig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/jdo408 276-5638 mailto:[EMAIL PROTECTED]P.S. A good JDO? O, Gasp! 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
Re: Issue 152: Redundant IMPORTS keyword
Hi Matthew, Provided that we could use "import" or "IMPORT", that would be fine. this would be the first case that we support a Java keyword in its upper case form. According to the spec keywords include Java keywords and JDOQL keywords. Only the JDOQL keywords have an all-lower-case and an all-upper-case form. So support for the upper case version IMPORT seems to be inconsistent with the above rule. An alternative, although not so compatible between the API and string versions, is to support the keyword "import" followed by a comma-separated, semicolon-terminated list of imports: I don't have a strong opinion about the comma separation, but if we want to support this we need to do the same for the declaration of variables. What I really do not like is making a difference between the API version and the single-string representation of a JDOQL query. This is confusing for the user and requires two different implementations of the import handling. I support the original proposal which just skips the keyword IMPORTS. Regards Michael SELECT UNIQUE firstname, lastname INTO FullName FROM Employee WHERE salary > 1000 && projects.contains(p) && p.budget > 3 VARIABLES Project p IMPORT org.apache.jdo.tck.query.result.classes.FullName, org.apache.jdo.tck.pc.company.Person, org.apache.jdo.tck.pc.company.Project; If we updated the spec (14.6.4) to allow this comma-separated, semicolon-terminated list in addition to the initial syntax, I think it would be intuitive: 14.6.4 Import statements The import statements follow the Java syntax for import statements. Import on demand is supported. Additionally, import statements may be expressed as a comma-separated, semicolon-terminated list of elements. For example, both import org.example.Foo; import org.example.Bar; import org.example.util.*; and import org.example.Foo, org.example.Bar, org.example.util.*; would be supported. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 27, 2005 7:01 PM To: JDO Expert Group; Apache JDO project Subject: Issue 152: Redundant IMPORTS keyword Javadogs, The keyword IMPORTS seems to be redundant. It introduces a series of statements each of which begins "import ...;". The keyword import could stand alone without the introductory IMPORTS. I think it would be better if we omitted the IMPORTS keyword entirely, so e.g. instead of: SELECT UNIQUE firstname, lastname INTO FullName FROM Employee WHERE salary > 1000 && projects.contains(p) && p.budget > 3 VARIABLES Project p IMPORTS import org.apache.jdo.tck.query.result.classes.FullName; import org.apache.jdo.tck.pc.company.Person import org.apache.jdo.tck.pc.company.Project; we would have: SELECT UNIQUE firstname, lastname INTO FullName FROM Employee WHERE salary > 1000 && projects.contains(p) && p.budget > 3 VARIABLES Project p import org.apache.jdo.tck.query.result.classes.FullName; import org.apache.jdo.tck.pc.company.Person import org.apache.jdo.tck.pc.company.Project; Craig 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! -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: [VOTE] Issue 139: Add attribute field-type to element field
Hi Craig, Hi Andy, I don't have a problem with using the element-type to be a comma-separated list as a vendor extension, but in general there is no way to map a heterogeneous (Object or interface type) field. does this apply the metadata attributes field-type, element-type, key-type and value-type? So I don't think that we should specify the comma-separated list of possible types as a standard technique. What do others think about this? I think support for a field with multiple types in its field-type attribute should not be required. But maybe it makes sense to specify the syntax as a comma separated list of type names in case a JDO implementation does support this feature. Regards Michael Craig On Dec 21, 2005, at 12:11 AM, Andy Jefferson wrote: Hi Craig, This proposal would allow more specific field type to be specified at deployment time compared to compile time. For example, a field of type Object could be specified in the jdo metadata as containing only instances of type SimpleClass. I don't read the proposal as saying that the user should specify the type(s) as comma-separated if they want a field declared as Object to store class A or class B or class C. What does the user do when they have a field declared as Object and want to do this ? -- Andy 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! -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: svn commit: r359353 - in /db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query: api/SingleStringQuery.java jdoql/keywords/SingleString.java
Hi Craig,
I think your checkin was the only missing action item for JDO-243. Any
objections if I set JDO-243 to resolved?
Regards Michael
Author: clr
Date: Tue Dec 27 18:41:36 2005
New Revision: 359353
URL: http://svn.apache.org/viewcvs?rev=359353&view=rev
Log:
JDO-243 changed ordering to a grouped field
Modified:
db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/api/SingleStringQuery.java
db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/jdoql/keywords/SingleString.java
Modified:
db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/api/SingleStringQuery.java
URL:
http://svn.apache.org/viewcvs/db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/api/SingleStringQuery.java?rev=359353&r1=359352&r2=359353&view=diff
==
---
db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/api/SingleStringQuery.java
(original)
+++
db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/api/SingleStringQuery.java
Tue Dec 27 18:41:36 2005
@@ -63,7 +63,7 @@
"import org.apache.jdo.tck.pc.company.Project; " +
"import java.math.BigDecimal; " +
"GROUP BY firstname, lastname " +
-"ORDER BY personid ASCENDING " +
+"ORDER BY lastname ASCENDING " +
"RANGE 0,5";
/**
Modified:
db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/jdoql/keywords/SingleString.java
URL:
http://svn.apache.org/viewcvs/db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/jdoql/keywords/SingleString.java?rev=359353&r1=359352&r2=359353&view=diff
==
---
db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/jdoql/keywords/SingleString.java
(original)
+++
db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/jdoql/keywords/SingleString.java
Tue Dec 27 18:41:36 2005
@@ -62,7 +62,7 @@
/*IMPORTS*/ "import org.apache.jdo.tck.pc.company.Project; " +
"import java.math.BigDecimal",
/*GROUP BY*/"firstname, lastname HAVING lastname.startsWith('emp')",
-/*ORDER BY*/"personid ASCENDING",
+/*ORDER BY*/"lastname ASCENDING",
/*FROM*/0,
/*TO*/ 3)
};
--
Michael Bouschen[EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED]http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
Re: svn commit: r359353 - in /db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query: api/SingleStringQuery.java jdoql/keywords/SingleString.java
No objections. I should have done so.Regards,CraigOn Dec 28, 2005, at 1:38 PM, Michael Bouschen wrote:Hi Craig,I think your checkin was the only missing action item for JDO-243. Any objections if I set JDO-243 to resolved?Regards Michael Author: clrDate: Tue Dec 27 18:41:36 2005New Revision: 359353URL: http://svn.apache.org/viewcvs?rev=359353&view=revLog:JDO-243 changed ordering to a grouped fieldModified: db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/api/SingleStringQuery.java db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/jdoql/keywords/SingleString.javaModified: db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/api/SingleStringQuery.javaURL: http://svn.apache.org/viewcvs/db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/api/SingleStringQuery.java?rev=359353&r1=359352&r2=359353&view=diff==--- db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/api/SingleStringQuery.java (original)+++ db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/api/SingleStringQuery.java Tue Dec 27 18:41:36 2005@@ -63,7 +63,7 @@ " import org.apache.jdo.tck.pc.company.Project; " + " import java.math.BigDecimal; " + "GROUP BY firstname, lastname " +- "ORDER BY personid ASCENDING " ++ "ORDER BY lastname ASCENDING " + "RANGE 0,5"; /** Modified: db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/jdoql/keywords/SingleString.javaURL: http://svn.apache.org/viewcvs/db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/jdoql/keywords/SingleString.java?rev=359353&r1=359352&r2=359353&view=diff==--- db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/jdoql/keywords/SingleString.java (original)+++ db/jdo/trunk/tck20/test/java/org/apache/jdo/tck/query/jdoql/keywords/SingleString.java Tue Dec 27 18:41:36 2005@@ -62,7 +62,7 @@ /*IMPORTS*/ "import org.apache.jdo.tck.pc.company.Project; " + "import java.math.BigDecimal", /*GROUP BY*/ "firstname, lastname HAVING lastname.startsWith('emp')",- /*ORDER BY*/ "personid ASCENDING",+ /*ORDER BY*/ "lastname ASCENDING", /*FROM*/ 0, /*TO*/ 3) }; -- Michael Bouschen [EMAIL PROTECTED] Engineering GmbHmailto:[EMAIL PROTECTED] http://www.tech.spree.de/Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin 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
[jira] Resolved: (JDO-243) JPOX must throw JDOUserException for group by queries which select non-grouped fields.
[ http://issues.apache.org/jira/browse/JDO-243?page=all ] Michael Bouschen resolved JDO-243: -- Resolution: Fixed Craig just checked in the remaining part of this issue and changed ordering to a grouped field in TCK query tests SingleStringQuery and SingleString. > JPOX must throw JDOUserException for group by queries which select > non-grouped fields. > -- > > Key: JDO-243 > URL: http://issues.apache.org/jira/browse/JDO-243 > Project: JDO > Type: Bug > Components: tck20 > Reporter: Michael Watzek > Assignee: Michael Watzek > > Test case Grouping fails for the query below. The query is expected to throw > a JDOUserException because field salary is contained in the result clause and > not contained in the group by clause. > 14:22:49,328 (main) DEBUG [org.apache.jdo.tck] - Compiling API query: SELECT > department, salary FROM org.apache.jdo.tck.pc.company.Employee GROUP BY > department > 14:22:49,328 (main) DEBUG [org.apache.jdo.tck] - Query compilation must throw > JDOUserException: null > 14:22:49,328 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: Assertion A14.6.10-1 (Grouping) failed: > Query compilation must throw JDOUserException: null > at junit.framework.Assert.fail(Assert.java:47) > at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546) > at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:915) > at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:878) > at > org.apache.jdo.tck.query.QueryTest.compileAPIQuery(QueryTest.java:793) > at > org.apache.jdo.tck.query.result.Grouping.testNegative(Grouping.java:122) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at junit.framework.TestCase.runTest(TestCase.java:154) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.textui.TestRunner.doRun(TestRunner.java:116) > at junit.textui.TestRunner.doRun(TestRunner.java:109) > at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) > at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Clarification needed on class names in query filters
Hi Andy, I agree JDOQL should support accessing static fields of an arbitrary class and not just of java.lang classes. I like your proposal: "... members of the candidate class, or they are qualified by the class and can be resolved to a static field of that name in the specified class". Please note this includes that the the class qualifier might be a fully qualified class name. So for a path expression 'a.b.c' the query compiler needs to analyze the entire path expression, before it can decide that 'a' is an implicit variable. Regards Michael Hi Craig, Names in the filter are treated as parameters if they are explicitly declared via declareParameters or if they begin with “:”. A14.6.5-4 [Names are treated as variable names if they are explicitly declared via declareVariables. Otherwise, names are treated as field names if they are members of the candidate class. Finally, names are treated as implicitly defined variable names.] Any suggestions for improvement? How about this :- Names in the filter are treated as parameters if they are explicitly declared via declareParameters or if they begin with “:”. Names are treated as variable names if they are explicitly declared via declareVariables. Names are treated as field names if they are either members of the candidate class, or they are qualified by the class and can be resolved to a static field of that name in the specified class. Otherwise, names are treated as implicitly defined variable names. This then allows access to static fields in *all* classes and not just the java.lang classes. So a user can specify Integer.MAX_VALUE, MyClass.MY_STATIC_FIELD, java.awt.Color.BLACK or whatever and since they are prefixed by the class name, the (static) field will be found and can be used. -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: [VOTE] Issue 150: Consistency requirements for relationships with mapped-by
Hi Craig, +1 Regards Michael Javadogs, I'll hold this vote open until January 2. [ ] Adopt the proposal below. If two relationships (one on each side of an association) are mapped to the same column, the field on only one side of the association needs to be explicitly mapped. The field on the other side of the relationship can be mapped by using the mapped-by attribute identifying the field on the side that defines the mapping. Regardless of which side changes the relationship, flush (whether done as part of commit or explicitly by the user) will modify the datastore to reflect the change and will update the memory model for consistency. There is no further behavior implied by having both sides of the relationship map to the same database column(s). In particular, making a change to one side of the relationship does not imply any runtime behavior by the JDO implementation to change the other side of the relationship in memory prior to flush, and there is no requirement to load fields affected by the change if they are not already loaded. This implies that if the RetainValues flag or DetachAllOnCommit is set to true, and the relationship field is loaded, then the implementation will change the field on the other side so it is visible after transaction completion. Conflicting changes to relationships cause a JDOUserException to be thrown at flush time. Conflicting changes include: adding a related instance with a single-valued mapped-by relationship field to more than one one-to-many collection relationship setting both sides of a one-to-one relationship such that they do not refer to each other On Dec 21, 2005, at 11:23 AM, Craig L Russell wrote: Hi David, Thanks for your comments. 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. So I took a fresh look at the requirements and practical aspects of implementation. JDO 1.0 requires byte-code enhancement. JDO 2.0 now admits implementations that don't use byte-code enhancement, weaving, or aspects in order to intercept domain model changes during a transaction. Synchronizing the memory model with the database is now deferred to flush (which might happen during commit). At flush time, the JDO implementation gets control (possibly for the first time after loading the instances) and can do whatever the spec requires. It's evident to me that it's possible to detect changes to either side of the relationship and make the two sides consistent. The proposal is carefully worded to not require that the implementation do extra work in case the memory model is not fully instantiated. In particular, it's possible to add a hollow Employee to a Department.emps collection without instantiating the Employee instance. Similarly, it's possible to set the Employee.dept field to a hollow Department without instantiating the Department instance. The original wording in the JDO 2.0 spec was informed by the work in EJB3 which derived from TopLink and Hibernate implementations that don't worry much about the "mapped-by" side of the relationship. But 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. This proposal is where I ended up. 1. JDO implementations get control at flush; 2. User changes should not be ignored; 3. Inconsistencies should not be accepted, as they indicate user code gone bad. I agree it's a tradeoff. I'd like to see managed relationships in memory but given the constraints I don't see it happening for JDO 2. And I'd really like to see managed relationships be a separate issue addressed in another JSR. It's not just a persistence issue; it's not a mapping issue; it's a domain model issue. Regards, Craig Slightly updated for clarity: On Dec 21, 2005, at 3:52 AM, David Bullock wrote: Bin Sun wrote: Think that without managed relation, if I modify one side and commit, I can't see the other side changed accordingly. But If I restart the JDO engine (such as restarting the web-server), I can see the change then, since it uses the same column referred by 'mapped by'. So, without any JDO operation, we'll see different result at different time (before and after restarting), this becomes a real consistency problem. As the spec and the proposal stands, you still have a consistency problem before and after commit. I'm interested to hear why the consistency issue only matters between server restarts, but not between before- and after- commit. cheers, David. 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! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 2
Re: Clarification needed on class names in query filters
Hi,On Dec 28, 2005, at 2:04 PM, Michael Bouschen wrote:Hi Andy,I agree JDOQL should support accessing static fields of an arbitrary class and not just of java.lang classes. It already does, and this section just hasn't been updated for it.A14.6.2-43 [Identifiers that are persistent field names or public final static field names are required to be supported by JDO implementations.] Other identifiers might be supported but are not required. Thus, portable queries must not use fields other than persistent or public final static field names in filter expressions.I like your proposal: "... members of the candidate class, or they are qualified by the class and can be resolved to a static field of that name in the specified class". Please note this includes that the the class qualifier might be a fully qualified class name. So for a path _expression_ 'a.b.c' the query compiler needs to analyze the entire path _expression_, before it can decide that 'a' is an implicit variable.I was hoping for a rule that would allow the compiler to determine that "a" is a class name not an implicit variable, without using the existence of b.c in a to determine it. Due to the common practice of starting variable names with lower-case and classes with upper-case, I think that this is probably a corner case. But I'm still hoping that we can have an unambiguous rule, inserting something into the rule below after "names are treated as field names if they are members of the candidate class": "Names are treated as a class name if it exists in the package of the candidate class or has been imported".CraigRegards Michael Hi Craig, Names in the filter are treated as parameters if they are explicitlydeclared via declareParameters or if they begin with “:”. A14.6.5-4[Names are treated as variable names if they are explicitly declaredvia declareVariables. Otherwise, names are treated as field names ifthey are members of the candidate class. Finally, names are treatedas implicitly defined variable names.]Any suggestions for improvement? How about this :-Names in the filter are treated as parameters if they are explicitlydeclared via declareParameters or if they begin with “:”.Names are treated as variable names if they are explicitly declaredvia declareVariables.Names are treated as field names if they are either members of the candidate class, or they are qualified by the class and can be resolved to a static field of that name in the specified class.Otherwise, names are treated as implicitly defined variable names.This then allows access to static fields in *all* classes and not just the java.lang classes. So a user can specify Integer.MAX_VALUE, MyClass.MY_STATIC_FIELD, java.awt.Color.BLACK or whatever and since they are prefixed by the class name, the (static) field will be found and can be used. -- Michael Bouschen [EMAIL PROTECTED] Engineering GmbHmailto:[EMAIL PROTECTED] http://www.tech.spree.de/Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin 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
Re: User demand and Issue 150. [was Re: Issue 150: Consistency requirements for relationships with mapped-by]
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.
--- David Bullock <[EMAIL PROTECTED]> wrote:
> Bin Sun wrote:
>
> >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.
> >
> >
>
> Hi Bin,
>
> Thanks for your sharing your experiences. This is
> what I was wanting -
> a justification from a real live user!
>
> But I have a quibble with your statement: "if the
> coder has to assign
> both sides, the other side (usually a collection)
> has to be loaded into
> memory".
>
> So you're saying that if I have persistent objects
> just so:
>
> public class Invoice {
>private Set 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.
>
> Hence there is no performance hit when setting both
> sides 'manually'.
>
> Please hasten to correct me if I've misunderstood
> why the performance
> hit takes place.
>
> cheers,
> David.
>
>
> [1] Not that there are many takers for my money
> anymore since JSR 220
> 'took over' persistence.
>
__
Yahoo! for Good - Make a difference this year.
http://brand.yahoo.com/cybergivingweek2005/
User demand and Issue 150. [was Re: Issue 150: Consistency requirements for relationships with mapped-by]
Bin Sun wrote:
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.
Hi Bin,
Thanks for your sharing your experiences. This is what I was wanting -
a justification from a real live user!
But I have a quibble with your statement: "if the coder has to assign
both sides, the other side (usually a collection) has to be loaded into
memory".
So you're saying that if I have persistent objects just so:
public class Invoice {
private Set 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.
Hence there is no performance hit when setting both sides 'manually'.
Please hasten to correct me if I've misunderstood why the performance
hit takes place.
cheers,
David.
[1] Not that there are many takers for my money anymore since JSR 220
'took over' persistence.
Re: User demand and Issue 150. [was Re: Issue 150: Consistency requirements for relationships with mapped-by]
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.
