tag:old.nabble.com,2006:forum-23350Nabble - Apache JDO2009-11-30T00:11:49Z<a href="http://db.apache.org/jdo/" target="_top" rel="nofollow">Java Data Objects (JDO)</a> is a standard way to access persistent data in databases, using plain old Java objects (POJO) to represent persistent data. The approach separates data manipulation (done by accessing Java data members in the Java domain objects) from database manipulation (done by calling the JDO interface methods). This separation of concerns leads to a high degree of independence of the Java view of data from the database view of the data.tag:old.nabble.com,2006:post-26571184Re: Support for if-then-else in JDOQL2009-11-30T00:11:49Z2009-11-30T00:11:49ZMichael Bouschen-2Hi,
<br><br>I filed a JIRA for adding support for a conditional operator ? : in
<br>JDOQL: <a href="https://issues.apache.org/jira/browse/JDO-650" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-650</a><br><br>Regards Michael
<br><br>> Hello.
<br>>
<br>> I am implementing the shortcut form for if-then-else (x ? y : c) in
<br>> Querydsl.
<br>>
<br>> Is there support for it in JDOQL? If not, could it be added?
<br>>
<br>> Br,
<br>> Timo Westkämper.
<br><br>--
<br>*Michael Bouschen*
<br>*Prokurist*
<br><br>akquinet tech@spree GmbH
<br>Bülowstr. 66, D-10783 Berlin
<br><br>Fon: +49 30 235 520-33
<br>Fax: +49 30 217 520-12
<br>Email: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26571184&i=0" target="_top" rel="nofollow">michael.bouschen@...</a>
<br>Url: www.akquinet.de <<a href="http://www.akquinet.de" target="_top" rel="nofollow">http://www.akquinet.de</a>>
<br><br>akquinet tech@spree GmbH, Berlin
<br>Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
<br>Amtsgericht Berlin-Charlottenburg HRB 86780 B
<br>USt.-Id. Nr.: DE 225 964 680
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26565941[jira] Created: (JDO-650) Support for conditional operator ? : in JDOQL2009-11-29T12:51:20Z2009-11-29T12:51:20ZJIRA jira@apache.orgSupport for conditional operator ? : in JDOQL
<br>---------------------------------------------
<br><br> Key: JDO-650
<br> URL: <a href="https://issues.apache.org/jira/browse/JDO-650" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-650</a><br> Project: JDO
<br> Issue Type: New Feature
<br> Components: specification, tck2
<br> Affects Versions: JDO 2 maintenance release 2
<br> Reporter: Michael Bouschen
<br> Assignee: Michael Bouschen
<br><br><br>JDOQL should support the Java conditional operator ? :, e.g. salay >= 1000.0 ? salary : salary * 1.1
<br><br>The conditional operator can be mapped to the CASE-expression in SQL: CASE WHEN condition THEN thenExpr ELSE elseExpr END. Are there any issues with non-SQL datastores when supporting the conditional operator?
<br><br>Another question: which part of a JDOQL query can include a conditional expression? I propose the query filter, the having clause and the result specification.
<br><br><br><br><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26447476Minutes: JDO TCK Conference Call Friday, Nov 20 9 am PDT2009-11-20T09:46:21Z2009-11-20T09:46:21ZCraig L RussellNOTE: We will take a brief hiatus for Thanksgiving break; next call
<br>will occur on December 4
<br><br>Attendees: Michelle Caisse, Michael Bouschen, Craig Russell
<br><br>Agenda:
<br><br>1. Query timeout in JDO / Update timeout
<br><br>a. Should we have different settings for query/read versus insert/
<br>update/delete? Jorg says that *update* operations might need their own
<br>setting.
<br><br>b. Should the timeout apply to *any* in-vm operations, or just to
<br>datastore operations? The original rationale for timeout was
<br>specifically to allow setting the underlying datastore timeout value.
<br><br>c Should we rename the property/api something like DatastoreRead and
<br>DatastoreWrite? This might make it more clear that queries,
<br>getObjectById, refresh, and others are affected.
<br><br>AI Craig update the JIRA with new proposal
<br><br>2. Query objects and hashCode() + equals()
<br><br>This issue looks like it has been resolved. If further action is
<br>necessary, please file a JIRA.
<br><br>3. Dependence of RI on JPA2
<br><br>Looks like this issue is moot. Based on our changes to JDO 2.3 and the
<br>fact that JPA2 is now in JCP vote, there are no timing issues.
<br><br>4. Other issues
<br><br>If-then-else support for JDOQL: It looks like JPA2 will support this;
<br>SQL supports it; are there any issues with non-SQL datastores?
<br><br>Action Items from weeks past:
<br><br>AI Nov 13 08 Michael: Take a look at what changes would be needed in
<br>the BNF to support for if-then-else in JDOQL, reply to the original
<br>email, open a JIRA
<br><br>Craig L Russell
<br>Architect, Sun Java Enterprise System <a href="http://db.apache.org/jdo" target="_top" rel="nofollow">http://db.apache.org/jdo</a><br>408 276-5638 mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26447476&i=0" target="_top" rel="nofollow">Craig.Russell@...</a>
<br>P.S. A good JDO? O, Gasp!
<br><br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (3K) <a href="http://old.nabble.com/attachment/26447476/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26440701Re: query timeout in JDO2009-11-20T01:46:20Z2009-11-20T01:46:20ZChristian ErnstHi !
<br><br>Michael Bouschen <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26440701&i=0" target="_top" rel="nofollow">mbo.tech@...</a>> wrote on 17.11.2009 09:05:24:
<br><div class='shrinkable-quote'><br>> query timeout in JDO
<br>>
<br>> Hi,
<br>>
<br>> the current spec allows specifying a query timeout on a Query, a PM
<br>> or a PMF. The PM defines the default for all Query instances of the
<br>> PM and the PMF defines the default value for all PMs of that PMF.
<br>> However, there are still three open issue in the query timeout area:
<br>>
<br>> (1) query timeout as an optional feature
<br>> I propose to add query timeout as an optional feature. This means
<br>> the collection returned by the PMF method supportedOptions includes
<br>> the string "javax.jdo.option.QueryTimeout", if the JDO
<br>> implementation and the datastore bound to the PMF supports query
<br>> timeout. This would be a change in chapter 11.6 "Optional Feature
<br>> Support" of the spec.
</div><br>Sounds fine as there might exists datastores which doesn't support these
<br>feature.
<br><div class='shrinkable-quote'><br>> (2) Scope of the query timeout value
<br>> I propose that a query timeout value set for a PM applies to all
<br>> "datastore query" operations issued by the PM. This includes
<br>> relationship navigation, findByObjectId and lasy loading of collections.
<br>> But how about modifying operations such as update, delete and
<br>> insert? Does it make sense to apply the PM's query timeout for these
<br>> operationsas well? I think this makes sense, but it might be less
<br>> obvious, because these operations are part of the transaction
<br>> commit. See also Jörg's recent email with subject "update timeout".
<br>> This would be a change in chapter 12 PersistenceManager. Today
<br>> chapter 12.6.3 "Query factory interface" specifies method
<br>> setQueryTimeout. If we broaden the scope of a query timeout set on a
<br>> PM, it might make sense to specify this in its own section, e.g. 12.
<br>> 6.9 "Query Timeout".
</div><br>The "Query Timeout" shall be an option only for the JDO queries themself.
<br>Keep in mind that the idea of JDO was to support any kind of datastore,
<br>which means there exists implementations which don't use any kind of
<br>datastore queries for operations like relationship navigation,
<br>findByObjectId and lasy loading of collections.
<br><div class='shrinkable-quote'><br>> (3) Definition of query timeout: datastore operation or JDO method?
<br>> Does the query timeout apply to the underlying datastore operation
<br>> or does it define the maximum execution time of the JDO method such
<br>> as Query.execute?
<br>> I propose the former, meaning use the query timeout value for the
<br>> datastore operation. Otherwise, the JDO implementation would need to
<br>> calculate the timeout for the datastore operation and need o guess
<br>> the time needed to post-process the query result. If the datastore
<br>> has the JDBC standard second resolution, and there is less than 1000
<br>> millis left in the timeout, what should be the timeout set on the
<br>> datastore query statement?
</div><br>From the JDO idea it should be on the operation of the
<br>Query.execute(), but from a Vendor persective i would suggest that
<br>we allow both and it shouldn't be gurantied that this value is exact,
<br>as the underlying datastore might have some kind of tolerance for the
<br>timeout
<br>or has different resolution for there timer.
<br><br><br>cheers
<br>Christian
<br>---
<br>Christian Ernst
<br>Software Engineer
<br><br>Tel: +49-40-60990 338
<br>Fax: +49-40-60990 113
<br>EMail: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26440701&i=1" target="_top" rel="nofollow">cernst@...</a>
<br><br>Versant GmbH
<br>Wiesenkamp 22b
<br>22359 Hamburg
<br>Germany
<br><br>Think Outside the Grid!
<br><a href="http://www.versant.com" target="_top" rel="nofollow">http://www.versant.com</a><br><br>Versant GmbH is incorporated in Germany.
<br>Company registration number: HRB 54723, Amtsgericht Hamburg.
<br>Registered Office: Wiesenkamp 22b, 22359 Hamburg, Germany.
<br>Geschäftsführer: Jochen Witte
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26438101Re: JDO TCK Conference Call Friday, Nov 20 9 am PDT2009-11-19T20:05:02Z2009-11-19T20:05:02ZMichelle Caisse-2Hi,
<br><br>We will have our regular meeting Friday, November 20 at 9 am PDT to
<br>discuss JDO TCK issues and status.
<br><br>Dial-in numbers are:
<br>Domestic (toll-free): 866 230-6968
<br>International (caller-paid): +1 213 787-0528
<br>Access code : 294-0479#
<br><br>Agenda:
<br><br>1. Query timeout in JDO / Update timeout
<br>2. Query objects and hashCode() + equals()
<br>3. Dependence of RI on JPA2
<br>4. Other issues
<br><br>Action Items from weeks past:
<br>AI Nov 13 08 Michael: Take a look at what changes would be needed in the
<br>BNF to support for if-then-else in JDOQL, reply to the original email
<br><br>-- Michelle
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26438068[jira] Resolved: (JDO-644) Change JTA 1.1 dependency artifact id from "transaction-api" to "jta"2009-11-19T19:56:39Z2009-11-19T19:56:39ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Michelle Caisse resolved JDO-644.
<br>---------------------------------
<br><br> Resolution: Fixed
<br><br>Completed with revision 882404
<br><div class='shrinkable-quote'><br>> Change JTA 1.1 dependency artifact id from "transaction-api" to "jta"
<br>> ---------------------------------------------------------------------
<br>>
<br>> Key: JDO-644
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-644" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-644</a><br>> Project: JDO
<br>> Issue Type: Improvement
<br>> Components: api2, api2-legacy, core2, enhancer2, fostore2, model2, query2, runtime2, tck2, tck2-legacy, util2
<br>> Affects Versions: JDO 2 maintenance release 3
<br>> Reporter: Matthew T. Adams
<br>> Attachments: jta-01-new.patch, jta-01.patch
<br>>
<br>>
<br>> It appears that the Maven 2 artifact id for JTA 1.1 is "jta", not "transaction-api". The Maven 2 POM is here:
<br>> <a href="http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/transaction/jta/1.1/jta-1.1.pom" target="_top" rel="nofollow">http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/transaction/jta/1.1/jta-1.1.pom</a><br>> For Maven1, the Maven 1 artifact id is "transaction-api":
<br>> <a href="http://download.java.net/maven/1/javax.transaction/poms/transaction-api-1.1.pom" target="_top" rel="nofollow">http://download.java.net/maven/1/javax.transaction/poms/transaction-api-1.1.pom</a><br>> Since most users use Maven2, this should be updated to "jta" and we, the team producing JDO, should just manually install JTA 1.1 into our own local Maven 1 repository with the artifact id "jta", using the Maven 2. Without this, it is extremely annoying for users to have to work around this.
<br>> An alternative solution would be to upload to the Maven 1 central repo a copy of JTA 1.1 with artifact id "jta", but I don't how to do that.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26430224Re: query timeout in JDO2009-11-19T09:12:15Z2009-11-19T09:12:15ZJoerg von Frantzius-2Hi,
<br><br>I somehow got the feeling that having a single property for both query
<br>and and update timeouts will create confusion, if I got Michael right here.
<br><br>Imagine somebody wants to set an update timeout, but doesn't want to
<br>constrain the duration of queries (or have a higher timeout for
<br>queries). Now if he sets the update timeout on the PM level, then he'd
<br>have to unset the timeout for each and every query issued. That's
<br>assuming that the timeout on the PM level will apply to all Query
<br>objects created by the PM.
<br><br>I'd propose to have distinct properties for query and update timeouts.
<br>The RI has distinct methods for creating Statement objects for queries
<br>and updates already, so it shouldn't be hard to implement.
<br><br>Regards,
<br>Jörg
<br><br>On 11/17/2009 09:05 AM, Michael Bouschen wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> the current spec allows specifying a query timeout on a Query, a PM or
<br>> a PMF. The PM defines the default for all Query instances of the PM
<br>> and the PMF defines the default value for all PMs of that PMF.
<br>> However, there are still three open issue in the query timeout area:
<br>>
<br>> (1) query timeout as an optional feature
<br>> I propose to add query timeout as an optional feature. This means the
<br>> collection returned by the PMF method supportedOptions includes the
<br>> string "javax.jdo.option.QueryTimeout", if the JDO implementation and
<br>> the datastore bound to the PMF supports query timeout. This would be a
<br>> change in chapter 11.6 "Optional Feature Support" of the spec.
<br>>
<br>> (2) Scope of the query timeout value
<br>> I propose that a query timeout value set for a PM applies to all
<br>> "datastore query" operations issued by the PM. This includes
<br>> relationship navigation, findByObjectId and lasy loading of collections.
<br>> But how about modifying operations such as update, delete and insert?
<br>> Does it make sense to apply the PM's query timeout for these
<br>> operationsas well? I think this makes sense, but it might be less
<br>> obvious, because these operations are part of the transaction commit.
<br>> See also Jörg's recent email with subject "update timeout". This would
<br>> be a change in chapter 12 PersistenceManager. Today chapter 12.6.3
<br>> "Query factory interface" specifies method setQueryTimeout. If we
<br>> broaden the scope of a query timeout set on a PM, it might make sense
<br>> to specify this in its own section, e.g. 12.6.9 "Query Timeout".
<br>>
<br>> (3) Definition of query timeout: datastore operation or JDO method?
<br>> Does the query timeout apply to the underlying datastore operation or
<br>> does it define the maximum execution time of the JDO method such as
<br>> Query.execute?
<br>> I propose the former, meaning use the query timeout value for the
<br>> datastore operation. Otherwise, the JDO implementation would need to
<br>> calculate the timeout for the datastore operation and need o guess the
<br>> time needed to post-process the query result. If the datastore has the
<br>> JDBC standard second resolution, and there is less than 1000 millis
<br>> left in the timeout, what should be the timeout set on the datastore
<br>> query statement?
<br>>
<br>> What do you think?
<br>>
<br>> Regards Michael
</div></div><br>--
<br>____________________________________________________________________
<br>artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
<br>Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
<br>Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
<br>UST-Id. DE 217652550
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26394361Re: Query objects and hashCode() + equals()2009-11-17T09:44:56Z2009-11-17T09:44:56ZAndy Jefferson-4> all I could find in the docs was
<br>> <a href="http://www.datanucleus.org/extensions/query_cache.html" target="_top" rel="nofollow">http://www.datanucleus.org/extensions/query_cache.html</a> which is about
<br>> caching of "query compilations". Or do you mean that it could be used to
<br>> store query results along with a cached QueryCompilation object?
<br><br>PMF prop(s)
<br><a href="http://www.datanucleus.org/products/accessplatform_2_0/persistence_properties.html#query" target="_top" rel="nofollow">http://www.datanucleus.org/products/accessplatform_2_0/persistence_properties.html#query</a><br><br>Query Cache(s)
<br><a href="http://www.datanucleus.org/products/accessplatform_2_0/jdo/query_cache.html" target="_top" rel="nofollow">http://www.datanucleus.org/products/accessplatform_2_0/jdo/query_cache.html</a><br><br>or look at the code ...
<br><br>--
<br>Andy
<br>DataNucleus (<a href="http://www.datanucleus.org" target="_top" rel="nofollow">http://www.datanucleus.org</a>)
<br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26394227Re: Query objects and hashCode() + equals()2009-11-17T09:38:00Z2009-11-17T09:38:00ZJoerg von Frantzius-2Hi Andy,
<br><br>all I could find in the docs was
<br><a href="http://www.datanucleus.org/extensions/query_cache.html" target="_top" rel="nofollow">http://www.datanucleus.org/extensions/query_cache.html</a> which is about
<br>caching of "query compilations". Or do you mean that it could be used to
<br>store query results along with a cached QueryCompilation object?
<br><br>On 11/17/2009 06:19 PM, Andy Jefferson wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>>> Our application framework caches the results of certain queries. It does
<br>>> not hand out the respective Query objects to application code, and it
<br>>> does not itself invoke any mutators on these Query objects.
<br>>>
<br>> DataNucleus v2.x also allows caching of query results (for non-legacy JDOQL
<br>> implementations). They are not cached by the "Query" object, but by a key that
<br>> represents the query string and the input parameters. Consequently no such map
<br>> lookup issues happen.
<br>>
<br>>
<br>>
</div></div><br>--
<br>____________________________________________________________________
<br>artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
<br>Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
<br>Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
<br>UST-Id. DE 217652550
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26393901Re: Query objects and hashCode() + equals()2009-11-17T09:19:44Z2009-11-17T09:19:44ZAndy Jefferson-4> Our application framework caches the results of certain queries. It does
<br>> not hand out the respective Query objects to application code, and it
<br>> does not itself invoke any mutators on these Query objects.
<br><br>DataNucleus v2.x also allows caching of query results (for non-legacy JDOQL
<br>implementations). They are not cached by the "Query" object, but by a key that
<br>represents the query string and the input parameters. Consequently no such map
<br>lookup issues happen.
<br><br><br>--
<br>Andy
<br>DataNucleus (<a href="http://www.datanucleus.org" target="_top" rel="nofollow">http://www.datanucleus.org</a>)
<br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26389115Re: Query objects and hashCode() + equals()2009-11-17T04:28:40Z2009-11-17T04:28:40ZCRombergHi Jörg,
<br><br>that the value of hashCode must not change, once an object is stored in a
<br>(hashCode aware) Map, might
<br>not be explicitly stated in the javadoc, but this is a natural
<br>requirement.
<br><br>The behavior of equals() then can actually change, provided the general
<br>equals/hashCode contract is respected,
<br>although a change of the behavior of equals() is in most cases not
<br>desirable.
<br><br>Changing the hashCode once an object is in a Map, breaks the Map contract.
<br><br>Changing equals behavior once an object is in a Map, does not break the
<br>Map contract, but the key
<br>that the value is to mapped to is changed.
<br><br>For tree structured, not hashCode aware maps, both can change within the
<br>limits of the equals/hashCode contract,
<br>but the total ordering imposed by the Comparator or the Comparable
<br>implementation must remain unchanged.
<br><br>The easiest implementation is basing hashCode, equals and compareTo on a
<br>(sub)set of the immutable fields.
<br><br>Cheers,
<br><br>Christian
<br><br><br><br><br><br>From:
<br>Joerg von Frantzius <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26389115&i=0" target="_top" rel="nofollow">joerg.von.frantzius@...</a>>
<br>To:
<br>Craig L Russell <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26389115&i=1" target="_top" rel="nofollow">Craig.Russell@...</a>>
<br>Cc:
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26389115&i=2" target="_top" rel="nofollow">jdo-dev@...</a>, JDO Expert Group <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26389115&i=3" target="_top" rel="nofollow">jdo-experts-ext@...</a>>
<br>Date:
<br>17.11.2009 12:55
<br>Subject:
<br>Re: Query objects and hashCode() + equals()
<br><br><br><br>Hi Craig,
<br><br>please see below...
<br><br>On 11/17/2009 12:52 AM, Craig L Russell wrote:
<br><br>[..]
<br>> Right. What I said is that for use as an element in a Set or as a key
<br>> in a Map, the instance should return the identical hashCode and behave
<br>> identically with respect to equals. So while the instance itself does
<br>> not have to be immutable, hashCode and equals should act on immutable
<br>> properties of the instance.
<br>I didn't find a hint in the javadocs that hashCode and equals should
<br>only act on immutable properties of the instance. But admittedly that's
<br>just nit-picking on my side, as I do agree that the Query objects must
<br>remain unchanged once they are put in a Set or used as a key in a HashMap.
<br>>
<br>> As I understand how these collections work, if you do change how
<br>> hashCode and equals behave after construction, the instance should be
<br>> removed from the collection and added again after the change is done.
<br>> This is pretty tricky in terms of synchronization and order of
<br>operation.
<br>That's true. So an application framework which uses Query objects as
<br>keys in a Map must not hand out Query objects to application code (and
<br>of course, once a Query object is put in a map, the framework must not
<br>invoke mutators on it).
<br><br>[..]
<br><br>>> I wouldn't ask if datanucleus wasn't already there halfway:
<br>datanucleus'
<br>>> JDO query object delegates to org.datanucleus.store.query.Query, which
<br>>> already correctly implements equals(), hashCode() and toString().
<br>>
<br>>
<br>> So does the query object change hashCode when the filter changes?
<br>Yes, it does.
<div class='shrinkable-quote'><br>>
<br>>> [..]
<br>>> Just a small thing, I hope I'll find the time to fix it in datanucleus
<br>>> myself. When that has happened, it could still be worth putting in
<br>>> the spec?
<br>>
<br>> I don't yet understand the use case. Can you be specific as to what
<br>> behavior you expect from a "proper implementation" of hashCode,
<br>> equals, and toString, and how the implementation would be exploited by
<br>> an application?
</div>Generally speaking, two Query objects should be equal if they represent
<br>the same query, i.e. they are equal if their execution at an ideally
<br>same point in time would yield the same result. The implementation of
<br>hashCode() should follow and fulfill the usual contract between equals()
<br>and hashCode().
<br><br>If that was given, I wouldn't have any requirements on the
<br>implementation of toString(). Currently datanucleus returns the
<br>single-string representation of the query, which is just great.
<br><br>Our application framework caches the results of certain queries. It does
<br>not hand out the respective Query objects to application code, and it
<br>does not itself invoke any mutators on these Query objects. A query
<br>result caching like that currently is hard to do when it is solely based
<br>on the spec, because neither equals(), hashCode() or toString() can
<br>reliably be used. It also is impossible for application (framework) code
<br>itself to build a cache key from a given Query object, because the Query
<br>interface does not provide any getters, e.g. for its filter etc. The
<br>only solution would be to separately remember the properties of the
<br>Query object when it is built.
<br><br>Regards,
<br>Jörg
<br><div class='shrinkable-quote'><br>>
<br>> Regards,
<br>>
<br>> Craig
<br>>>
<br>>> Regards,
<br>>> Jörg
<br>>>
<br>>> On 10/23/2009 06:57 PM, Craig L Russell wrote:
<br>>>> Hi Jörg,
<br>>>>
<br>>>> On Oct 16, 2009, at 9:50 AM, Joerg von Frantzius wrote:
<br>>>>
<br>>>>> Hi,
<br>>>>>
<br>>>>> it would be nice if the spec would mandate that implementations of
<br>>>>> javax.jdo.Query do correctly implement hashCode() and equals().
<br>>>>
<br>>>> As users execute mutator methods on queries, the string representation
<br>>>> would change. And for proper use in sets or map keys, hashCode and
<br>>>> equals should be immutable after construction. So I don't see how we
<br>>>> can mandate that hashCode and equals rely in any internal state.
<br>>>>
<br>>>>> Alternatively, Query.toString() could be required to return the
<br>>>>> single-string representation of the query, or some dedicated method
<br>>>>> was
<br>>>>> added to provide it.
<br>>>>>
<br>>>> Having the single-string version of a query is useful but adds
<br>>>> implementation complexity. While there is a requirement for an
<br>>>> implementation to parse a single string query into executable form,
<br>>>> there's no current requirement to create the single string form from
<br>>>> the internal form.
<br>>>>
<br>>>>> This would make it easier to e.g. implement some custom cache for
<br>>>>> query
<br>>>>> results, or, more generally, it would make it easier to put Query
<br>>>>> objects as keys into Maps.
<br>>>>
<br>>>> It seems to me that if you want this functionality at the application
<br>>>> framework layer, then the framework can mandate that the single string
<br>>>> form be used and at the time the query is created, the single string
<br>>>> form be used as the key into a framework map.
<br>>>>
<br>>>> Regards,
<br>>>>
<br>>>> Craig
<br>>>>> ____________________________________________________________________
<br>>>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
<br>>>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
<br>>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
<br>>>>> UST-Id. DE 217652550
<br>>>>>
<br>>>>
<br>>>> Craig L Russell
<br>>>> Architect, Sun Java Enterprise System <a href="http://db.apache.org/jdo" target="_top" rel="nofollow">http://db.apache.org/jdo</a><br>>>> 408 276-5638 mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26389115&i=4" target="_top" rel="nofollow">Craig.Russell@...</a>
<br>>>> P.S. A good JDO? O, Gasp!
<br>>>>
<br>>>
<br>>>
<br>>> --
<br>>> ____________________________________________________________________
<br>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
<br>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
<br>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
<br>>> UST-Id. DE 217652550
<br>>>
<br>>
<br>> Craig L Russell
<br>> Architect, Sun Java Enterprise System <a href="http://db.apache.org/jdo" target="_top" rel="nofollow">http://db.apache.org/jdo</a><br>> 408 276-5638 mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26389115&i=5" target="_top" rel="nofollow">Craig.Russell@...</a>
<br>> P.S. A good JDO? O, Gasp!
<br>>
</div><br><br>--
<br>____________________________________________________________________
<br>artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
<br>Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
<br>Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
<br>UST-Id. DE 217652550
<br><br>[attachment "joerg_von_frantzius.vcf" deleted by Christian
<br>Romberg/VERSANT]
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26388703Re: Query objects and hashCode() + equals()2009-11-17T03:54:09Z2009-11-17T03:54:09ZJoerg von Frantzius-2Hi Craig,
<br><br>please see below...
<br><br>On 11/17/2009 12:52 AM, Craig L Russell wrote:
<br><br>[..]
<br>> Right. What I said is that for use as an element in a Set or as a key
<br>> in a Map, the instance should return the identical hashCode and behave
<br>> identically with respect to equals. So while the instance itself does
<br>> not have to be immutable, hashCode and equals should act on immutable
<br>> properties of the instance.
<br>I didn't find a hint in the javadocs that hashCode and equals should
<br>only act on immutable properties of the instance. But admittedly that's
<br>just nit-picking on my side, as I do agree that the Query objects must
<br>remain unchanged once they are put in a Set or used as a key in a HashMap.
<br>>
<br>> As I understand how these collections work, if you do change how
<br>> hashCode and equals behave after construction, the instance should be
<br>> removed from the collection and added again after the change is done.
<br>> This is pretty tricky in terms of synchronization and order of operation.
<br>That's true. So an application framework which uses Query objects as
<br>keys in a Map must not hand out Query objects to application code (and
<br>of course, once a Query object is put in a map, the framework must not
<br>invoke mutators on it).
<br><br>[..]
<br><br>>> I wouldn't ask if datanucleus wasn't already there halfway: datanucleus'
<br>>> JDO query object delegates to org.datanucleus.store.query.Query, which
<br>>> already correctly implements equals(), hashCode() and toString().
<br>>
<br>>
<br>> So does the query object change hashCode when the filter changes?
<br>Yes, it does.
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>>
<br>>> [..]
<br>>> Just a small thing, I hope I'll find the time to fix it in datanucleus
<br>>> myself. When that has happened, it could still be worth putting in
<br>>> the spec?
<br>>
<br>> I don't yet understand the use case. Can you be specific as to what
<br>> behavior you expect from a "proper implementation" of hashCode,
<br>> equals, and toString, and how the implementation would be exploited by
<br>> an application?
</div>Generally speaking, two Query objects should be equal if they represent
</div>the same query, i.e. they are equal if their execution at an ideally
<br>same point in time would yield the same result. The implementation of
<br>hashCode() should follow and fulfill the usual contract between equals()
<br>and hashCode().
<br><br>If that was given, I wouldn't have any requirements on the
<br>implementation of toString(). Currently datanucleus returns the
<br>single-string representation of the query, which is just great.
<br><br>Our application framework caches the results of certain queries. It does
<br>not hand out the respective Query objects to application code, and it
<br>does not itself invoke any mutators on these Query objects. A query
<br>result caching like that currently is hard to do when it is solely based
<br>on the spec, because neither equals(), hashCode() or toString() can
<br>reliably be used. It also is impossible for application (framework) code
<br>itself to build a cache key from a given Query object, because the Query
<br>interface does not provide any getters, e.g. for its filter etc. The
<br>only solution would be to separately remember the properties of the
<br>Query object when it is built.
<br><br>Regards,
<br>Jörg
<br><div class='shrinkable-quote'><div class='shrinkable-quote'><br>>
<br>> Regards,
<br>>
<br>> Craig
<br>>>
<br>>> Regards,
<br>>> Jörg
<br>>>
<br>>> On 10/23/2009 06:57 PM, Craig L Russell wrote:
<br>>>> Hi Jörg,
<br>>>>
<br>>>> On Oct 16, 2009, at 9:50 AM, Joerg von Frantzius wrote:
<br>>>>
<br>>>>> Hi,
<br>>>>>
<br>>>>> it would be nice if the spec would mandate that implementations of
<br>>>>> javax.jdo.Query do correctly implement hashCode() and equals().
<br>>>>
<br>>>> As users execute mutator methods on queries, the string representation
<br>>>> would change. And for proper use in sets or map keys, hashCode and
<br>>>> equals should be immutable after construction. So I don't see how we
<br>>>> can mandate that hashCode and equals rely in any internal state.
<br>>>>
<br>>>>> Alternatively, Query.toString() could be required to return the
<br>>>>> single-string representation of the query, or some dedicated method
<br>>>>> was
<br>>>>> added to provide it.
<br>>>>>
<br>>>> Having the single-string version of a query is useful but adds
<br>>>> implementation complexity. While there is a requirement for an
<br>>>> implementation to parse a single string query into executable form,
<br>>>> there's no current requirement to create the single string form from
<br>>>> the internal form.
<br>>>>
<br>>>>> This would make it easier to e.g. implement some custom cache for
<br>>>>> query
<br>>>>> results, or, more generally, it would make it easier to put Query
<br>>>>> objects as keys into Maps.
<br>>>>
<br>>>> It seems to me that if you want this functionality at the application
<br>>>> framework layer, then the framework can mandate that the single string
<br>>>> form be used and at the time the query is created, the single string
<br>>>> form be used as the key into a framework map.
<br>>>>
<br>>>> Regards,
<br>>>>
<br>>>> Craig
<br>>>>> ____________________________________________________________________
<br>>>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
<br>>>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
<br>>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
<br>>>>> UST-Id. DE 217652550
<br>>>>>
<br>>>>
<br>>>> Craig L Russell
<br>>>> Architect, Sun Java Enterprise System <a href="http://db.apache.org/jdo" target="_top" rel="nofollow">http://db.apache.org/jdo</a><br>>>> 408 276-5638 mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26388703&i=0" target="_top" rel="nofollow">Craig.Russell@...</a>
<br>>>> P.S. A good JDO? O, Gasp!
<br>>>>
<br>>>
<br>>>
<br>>> --
<br>>> ____________________________________________________________________
<br>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
<br>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
<br>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
<br>>> UST-Id. DE 217652550
<br>>>
<br>>
<br>> Craig L Russell
<br>> Architect, Sun Java Enterprise System <a href="http://db.apache.org/jdo" target="_top" rel="nofollow">http://db.apache.org/jdo</a><br>> 408 276-5638 mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26388703&i=1" target="_top" rel="nofollow">Craig.Russell@...</a>
<br>> P.S. A good JDO? O, Gasp!
<br>>
</div></div><br>--
<br>____________________________________________________________________
<br>artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
<br>Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
<br>Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
<br>UST-Id. DE 217652550
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26386424[jira] Commented: (JDO-649) Upgrade "persistence-api.jar" for use with TCK to be JPA2 since DataNucleus 2.x uses that now2009-11-17T01:00:40Z2009-11-17T01:00:40ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778780#action_12778780" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778780#action_12778780</a> ]
<br><br>Andy Jefferson commented on JDO-649:
<br>------------------------------------
<br><br>But will JDO 2.3 really *depend on* JPA2 ? All I've changed here is that the RI for JDO2.3 just happens to also implement JPA2, so has references to JPA2 classes. JDO2.3 itself has no such references to JPA2 classes, and it is only the JDO 2.3 TCK that does due to the RI.
<br><div class='shrinkable-quote'><br>> Upgrade "persistence-api.jar" for use with TCK to be JPA2 since DataNucleus 2.x uses that now
<br>> ---------------------------------------------------------------------------------------------
<br>>
<br>> Key: JDO-649
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-649" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-649</a><br>> Project: JDO
<br>> Issue Type: Task
<br>> Components: tck2
<br>> Reporter: Andy Jefferson
<br>> Assignee: Andy Jefferson
<br>> Fix For: JDO 2 maintenance release 3
<br>>
<br>>
<br>> DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs" dependency. Was previously
<br>> <dependency>
<br>> <groupId>org.apache.geronimo.specs</groupId>
<br>> <artifactId>geronimo-jpa_3.0_spec</artifactId>
<br>> <version>1.0</version>
<br>> </dependency>
<br>> and should be
<br>> <dependency>
<br>> <groupId>org.apache.geronimo.specs</groupId>
<br>> <artifactId>geronimo-jpa_2.0_spec</artifactId>
<br>> <version>1.0-PFD2</version>
<br>> </dependency>
<br>> No idea why geronimo specs thinks JPA1 is "JPA 3.0" but anyway ...
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26385861query timeout in JDO2009-11-17T00:05:24Z2009-11-17T00:05:24ZMichael Bouschen-2Hi,
<br><br>the current spec allows specifying a query timeout on a Query, a PM or a
<br>PMF. The PM defines the default for all Query instances of the PM and
<br>the PMF defines the default value for all PMs of that PMF. However,
<br>there are still three open issue in the query timeout area:
<br><br>(1) query timeout as an optional feature
<br>I propose to add query timeout as an optional feature. This means the
<br>collection returned by the PMF method supportedOptions includes the
<br>string "javax.jdo.option.QueryTimeout", if the JDO implementation and
<br>the datastore bound to the PMF supports query timeout. This would be a
<br>change in chapter 11.6 "Optional Feature Support" of the spec.
<br><br>(2) Scope of the query timeout value
<br>I propose that a query timeout value set for a PM applies to all
<br>"datastore query" operations issued by the PM. This includes
<br>relationship navigation, findByObjectId and lasy loading of collections.
<br>But how about modifying operations such as update, delete and insert?
<br>Does it make sense to apply the PM's query timeout for these
<br>operationsas well? I think this makes sense, but it might be less
<br>obvious, because these operations are part of the transaction commit.
<br>See also Jörg's recent email with subject "update timeout". This would
<br>be a change in chapter 12 PersistenceManager. Today chapter 12.6.3
<br>"Query factory interface" specifies method setQueryTimeout. If we
<br>broaden the scope of a query timeout set on a PM, it might make sense to
<br>specify this in its own section, e.g. 12.6.9 "Query Timeout".
<br><br>(3) Definition of query timeout: datastore operation or JDO method?
<br>Does the query timeout apply to the underlying datastore operation or
<br>does it define the maximum execution time of the JDO method such as
<br>Query.execute?
<br>I propose the former, meaning use the query timeout value for the
<br>datastore operation. Otherwise, the JDO implementation would need to
<br>calculate the timeout for the datastore operation and need o guess the
<br>time needed to post-process the query result. If the datastore has the
<br>JDBC standard second resolution, and there is less than 1000 millis left
<br>in the timeout, what should be the timeout set on the datastore query
<br>statement?
<br><br>What do you think?
<br><br>Regards Michael
<br>--
<br>*Michael Bouschen*
<br>*Prokurist*
<br><br>akquinet tech@spree GmbH
<br>Bülowstr. 66, D-10783 Berlin
<br><br>Fon: +49 30 235 520-33
<br>Fax: +49 30 217 520-12
<br>Email: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26385861&i=0" target="_top" rel="nofollow">michael.bouschen@...</a>
<br>Url: www.akquinet.de <<a href="http://www.akquinet.de" target="_top" rel="nofollow">http://www.akquinet.de</a>>
<br><br>akquinet tech@spree GmbH, Berlin
<br>Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
<br>Amtsgericht Berlin-Charlottenburg HRB 86780 B
<br>USt.-Id. Nr.: DE 225 964 680
<br><br>--
<br>*Michael Bouschen*
<br>*Prokurist*
<br><br>akquinet tech@spree GmbH
<br>Bülowstr. 66, D-10783 Berlin
<br><br>Fon: +49 30 235 520-33
<br>Fax: +49 30 217 520-12
<br>Email: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26385861&i=1" target="_top" rel="nofollow">michael.bouschen@...</a>
<br>Url: www.akquinet.de <<a href="http://www.akquinet.de" target="_top" rel="nofollow">http://www.akquinet.de</a>>
<br><br>akquinet tech@spree GmbH, Berlin
<br>Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
<br>Amtsgericht Berlin-Charlottenburg HRB 86780 B
<br>USt.-Id. Nr.: DE 225 964 680
<br><br>--
<br>*Michael Bouschen*
<br>*Prokurist*
<br><br>akquinet tech@spree GmbH
<br>Bülowstr. 66, D-10783 Berlin
<br><br>Fon: +49 30 235 520-33
<br>Fax: +49 30 217 520-12
<br>Email: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26385861&i=2" target="_top" rel="nofollow">michael.bouschen@...</a>
<br>Url: www.akquinet.de <<a href="http://www.akquinet.de" target="_top" rel="nofollow">http://www.akquinet.de</a>>
<br><br>akquinet tech@spree GmbH, Berlin
<br>Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
<br>Amtsgericht Berlin-Charlottenburg HRB 86780 B
<br>USt.-Id. Nr.: DE 225 964 680
<br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26382232[jira] Commented: (JDO-649) Upgrade "persistence-api.jar" for use with TCK to be JPA2 since DataNucleus 2.x uses that now2009-11-16T16:09:39Z2009-11-16T16:09:39ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778662#action_12778662" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778662#action_12778662</a> ]
<br><br>Craig Russell commented on JDO-649:
<br>-----------------------------------
<br><br>This could use just a bit more discussion, since this means that JDO 2.3 *will depend* on JPA 2.
<br><br>The timing is probably right, but let's discuss this new dependency.
<br><div class='shrinkable-quote'><br>> Upgrade "persistence-api.jar" for use with TCK to be JPA2 since DataNucleus 2.x uses that now
<br>> ---------------------------------------------------------------------------------------------
<br>>
<br>> Key: JDO-649
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-649" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-649</a><br>> Project: JDO
<br>> Issue Type: Task
<br>> Components: tck2
<br>> Reporter: Andy Jefferson
<br>> Assignee: Andy Jefferson
<br>> Fix For: JDO 2 maintenance release 3
<br>>
<br>>
<br>> DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs" dependency. Was previously
<br>> <dependency>
<br>> <groupId>org.apache.geronimo.specs</groupId>
<br>> <artifactId>geronimo-jpa_3.0_spec</artifactId>
<br>> <version>1.0</version>
<br>> </dependency>
<br>> and should be
<br>> <dependency>
<br>> <groupId>org.apache.geronimo.specs</groupId>
<br>> <artifactId>geronimo-jpa_2.0_spec</artifactId>
<br>> <version>1.0-PFD2</version>
<br>> </dependency>
<br>> No idea why geronimo specs thinks JPA1 is "JPA 3.0" but anyway ...
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26382070Re: Query objects and hashCode() + equals()2009-11-16T15:52:45Z2009-11-16T15:52:45ZCraig L RussellHi Jörg,
<br><br>On Nov 16, 2009, at 8:32 AM, Joerg von Frantzius wrote:
<br><br>> Hi Craig,
<br>>
<br>> you are absolutely right about the Query object being mutable, and
<br>> this
<br>> conflicting with its use as a key in a HashMap. But telling from the
<br>> general contracts of Map, equals() and hashCode(), I don't think that
<br>> there exists a requirement for Map keys to be immutable.
<br><br>Right. What I said is that for use as an element in a Set or as a key
<br>in a Map, the instance should return the identical hashCode and behave
<br>identically with respect to equals. So while the instance itself does
<br>not have to be immutable, hashCode and equals should act on immutable
<br>properties of the instance.
<br><br>As I understand how these collections work, if you do change how
<br>hashCode and equals behave after construction, the instance should be
<br>removed from the collection and added again after the change is done.
<br>This is pretty tricky in terms of synchronization and order of
<br>operation.
<br><br>> There may also
<br>> be other purposes for comparing Query objects using equals(), or Map
<br>> implementations that don't require immutability of keys.
<br>>
<br>> I wouldn't ask if datanucleus wasn't already there halfway:
<br>> datanucleus'
<br>> JDO query object delegates to org.datanucleus.store.query.Query, which
<br>> already correctly implements equals(), hashCode() and toString().
<br><br>So does the query object change hashCode when the filter changes?
<br><br>> The
<br>> only thing missing is the wrapper query object to also delegate these
<br>> methods (I guess that was simply forgotten when that additional layer
<br>> was introduced with JPOX implementing JPA).
<br>>
<br>> Just a small thing, I hope I'll find the time to fix it in datanucleus
<br>> myself. When that has happened, it could still be worth putting in
<br>> the spec?
<br><br>I don't yet understand the use case. Can you be specific as to what
<br>behavior you expect from a "proper implementation" of hashCode,
<br>equals, and toString, and how the implementation would be exploited by
<br>an application?
<br><br>Regards,
<br><br>Craig
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>>
<br>> Regards,
<br>> Jörg
<br>>
<br>> On 10/23/2009 06:57 PM, Craig L Russell wrote:
<br>>> Hi Jörg,
<br>>>
<br>>> On Oct 16, 2009, at 9:50 AM, Joerg von Frantzius wrote:
<br>>>
<br>>>> Hi,
<br>>>>
<br>>>> it would be nice if the spec would mandate that implementations of
<br>>>> javax.jdo.Query do correctly implement hashCode() and equals().
<br>>>
<br>>> As users execute mutator methods on queries, the string
<br>>> representation
<br>>> would change. And for proper use in sets or map keys, hashCode and
<br>>> equals should be immutable after construction. So I don't see how we
<br>>> can mandate that hashCode and equals rely in any internal state.
<br>>>
<br>>>> Alternatively, Query.toString() could be required to return the
<br>>>> single-string representation of the query, or some dedicated
<br>>>> method was
<br>>>> added to provide it.
<br>>>>
<br>>> Having the single-string version of a query is useful but adds
<br>>> implementation complexity. While there is a requirement for an
<br>>> implementation to parse a single string query into executable form,
<br>>> there's no current requirement to create the single string form from
<br>>> the internal form.
<br>>>
<br>>>> This would make it easier to e.g. implement some custom cache for
<br>>>> query
<br>>>> results, or, more generally, it would make it easier to put Query
<br>>>> objects as keys into Maps.
<br>>>
<br>>> It seems to me that if you want this functionality at the application
<br>>> framework layer, then the framework can mandate that the single
<br>>> string
<br>>> form be used and at the time the query is created, the single string
<br>>> form be used as the key into a framework map.
<br>>>
<br>>> Regards,
<br>>>
<br>>> Craig
<br>>>> ____________________________________________________________________
<br>>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
<br>>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
<br>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
<br>>>> UST-Id. DE 217652550
<br>>>>
<br>>>
<br>>> Craig L Russell
<br>>> Architect, Sun Java Enterprise System <a href="http://db.apache.org/jdo" target="_top" rel="nofollow">http://db.apache.org/jdo</a><br>>> 408 276-5638 mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26382070&i=0" target="_top" rel="nofollow">Craig.Russell@...</a>
<br>>> P.S. A good JDO? O, Gasp!
<br>>>
<br>>
<br>>
<br>> --
<br>> ____________________________________________________________________
<br>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
<br>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
<br>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
<br>> UST-Id. DE 217652550
<br>>
</div></div>Craig L Russell
<br>Architect, Sun Java Enterprise System <a href="http://db.apache.org/jdo" target="_top" rel="nofollow">http://db.apache.org/jdo</a><br>408 276-5638 mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26382070&i=1" target="_top" rel="nofollow">Craig.Russell@...</a>
<br>P.S. A good JDO? O, Gasp!
<br><br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (3K) <a href="http://old.nabble.com/attachment/26382070/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26377442Re: Update timeout?2009-11-16T10:55:56Z2009-11-16T10:55:56ZCraig L RussellHi Jörg,
<br><br>This is a timely comment. We're just finalizing the query timeout
<br>issue and we should take care of this item as well for the 2.3 release.
<br><br>It's possible that we could use the same query timeout value that we
<br>set on the PersistenceManagerFactory and PersistenceManager to apply
<br>to both queries and updates/deletes. This would minimize the API
<br>"footprint" with no loss of expressiveness.
<br><br>So let's discuss the scope of the query timeout possibly to apply to
<br>delete and update operations as well.
<br><br>I agree that it's currently not possible to get access to the
<br>Statement that is being executed so you can set the timeout in the
<br>application. It has to be a JDO setting.
<br><br>Regards,
<br><br>Craig
<br><br>On Nov 16, 2009, at 9:27 AM, Joerg von Frantzius wrote:
<br><div class='shrinkable-quote'><div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> the other day we had the problem that a row lock got held indefinitely
<br>> in a production database, probably because of the appserver not
<br>> properly
<br>> committing a connection. As a consequence, the HTTP-threads of the
<br>> appserver got blocked one after the other, during execution of an
<br>> UPDATE
<br>> statement. This eventually lead to the whole appserver cluster to
<br>> hang,
<br>> when all HTTP thread pools were filled with blocked threads.
<br>>
<br>> The consequences of a single hanging row-lock could be much less
<br>> drastic
<br>> if something like an update timeout existed. I was hoping that
<br>> <a href="http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#setQueryTimeout(int" target="_top" rel="nofollow">http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#setQueryTimeout(int</a>)
<br>> applies to both SELECT and UPDATE statements, so that threads
<br>> blocked in
<br>> a UPDATE statement wouldn't do so forever.
<br>>
<br>> What do you think of having an additional
<br>> javax.jdo.option.UpdateTimeout
<br>> PMF property for this?
<br>>
<br>> Currently there is no way for an application to access any
<br>> java.sql.Statement object used by the JDO implementation to invoke
<br>> setQueryTimeout() by itself, so in order to have update timeouts with
<br>> JDO, some extension of the spec would be necessary?
<br>>
<br>> Regards,
<br>> Jörg
<br>>
<br>> --
<br>> ____________________________________________________________________
<br>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
<br>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
<br>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
<br>> UST-Id. DE 217652550
<br>>
<br>> <joerg_von_frantzius.vcf>
</div></div>Craig L Russell
<br>Architect, Sun Java Enterprise System <a href="http://db.apache.org/jdo" target="_top" rel="nofollow">http://db.apache.org/jdo</a><br>408 276-5638 mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26377442&i=0" target="_top" rel="nofollow">Craig.Russell@...</a>
<br>P.S. A good JDO? O, Gasp!
<br><br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (3K) <a href="http://old.nabble.com/attachment/26377442/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26375988Update timeout?2009-11-16T09:27:30Z2009-11-16T09:27:30ZJoerg von Frantzius-2Hi,
<br><br>the other day we had the problem that a row lock got held indefinitely
<br>in a production database, probably because of the appserver not properly
<br>committing a connection. As a consequence, the HTTP-threads of the
<br>appserver got blocked one after the other, during execution of an UPDATE
<br>statement. This eventually lead to the whole appserver cluster to hang,
<br>when all HTTP thread pools were filled with blocked threads.
<br><br>The consequences of a single hanging row-lock could be much less drastic
<br>if something like an update timeout existed. I was hoping that
<br><a href="http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#setQueryTimeout(int" target="_top" rel="nofollow">http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#setQueryTimeout(int</a>)
<br>applies to both SELECT and UPDATE statements, so that threads blocked in
<br>a UPDATE statement wouldn't do so forever.
<br><br>What do you think of having an additional javax.jdo.option.UpdateTimeout
<br>PMF property for this?
<br><br>Currently there is no way for an application to access any
<br>java.sql.Statement object used by the JDO implementation to invoke
<br>setQueryTimeout() by itself, so in order to have update timeouts with
<br>JDO, some extension of the spec would be necessary?
<br><br>Regards,
<br>Jörg
<br><br>--
<br>____________________________________________________________________
<br>artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
<br>Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
<br>Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
<br>UST-Id. DE 217652550
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26374939Re: Query objects and hashCode() + equals()2009-11-16T08:32:49Z2009-11-16T08:32:49ZJoerg von Frantzius-2Hi Craig,
<br><br>you are absolutely right about the Query object being mutable, and this
<br>conflicting with its use as a key in a HashMap. But telling from the
<br>general contracts of Map, equals() and hashCode(), I don't think that
<br>there exists a requirement for Map keys to be immutable. There may also
<br>be other purposes for comparing Query objects using equals(), or Map
<br>implementations that don't require immutability of keys.
<br><br>I wouldn't ask if datanucleus wasn't already there halfway: datanucleus'
<br>JDO query object delegates to org.datanucleus.store.query.Query, which
<br>already correctly implements equals(), hashCode() and toString(). The
<br>only thing missing is the wrapper query object to also delegate these
<br>methods (I guess that was simply forgotten when that additional layer
<br>was introduced with JPOX implementing JPA).
<br><br>Just a small thing, I hope I'll find the time to fix it in datanucleus
<br>myself. When that has happened, it could still be worth putting in the spec?
<br><br>Regards,
<br>Jörg
<br><br>On 10/23/2009 06:57 PM, Craig L Russell wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> Hi Jörg,
<br>>
<br>> On Oct 16, 2009, at 9:50 AM, Joerg von Frantzius wrote:
<br>>
<br>>> Hi,
<br>>>
<br>>> it would be nice if the spec would mandate that implementations of
<br>>> javax.jdo.Query do correctly implement hashCode() and equals().
<br>>
<br>> As users execute mutator methods on queries, the string representation
<br>> would change. And for proper use in sets or map keys, hashCode and
<br>> equals should be immutable after construction. So I don't see how we
<br>> can mandate that hashCode and equals rely in any internal state.
<br>>
<br>>> Alternatively, Query.toString() could be required to return the
<br>>> single-string representation of the query, or some dedicated method was
<br>>> added to provide it.
<br>>>
<br>> Having the single-string version of a query is useful but adds
<br>> implementation complexity. While there is a requirement for an
<br>> implementation to parse a single string query into executable form,
<br>> there's no current requirement to create the single string form from
<br>> the internal form.
<br>>
<br>>> This would make it easier to e.g. implement some custom cache for query
<br>>> results, or, more generally, it would make it easier to put Query
<br>>> objects as keys into Maps.
<br>>
<br>> It seems to me that if you want this functionality at the application
<br>> framework layer, then the framework can mandate that the single string
<br>> form be used and at the time the query is created, the single string
<br>> form be used as the key into a framework map.
<br>>
<br>> Regards,
<br>>
<br>> Craig
<br>>> ____________________________________________________________________
<br>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
<br>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
<br>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
<br>>> UST-Id. DE 217652550
<br>>>
<br>>
<br>> Craig L Russell
<br>> Architect, Sun Java Enterprise System <a href="http://db.apache.org/jdo" target="_top" rel="nofollow">http://db.apache.org/jdo</a><br>> 408 276-5638 mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26374939&i=0" target="_top" rel="nofollow">Craig.Russell@...</a>
<br>> P.S. A good JDO? O, Gasp!
<br>>
</div></div><br>--
<br>____________________________________________________________________
<br>artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
<br>Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
<br>Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
<br>UST-Id. DE 217652550
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26374375[jira] Resolved: (JDO-649) Upgrade "persistence-api.jar" for use with TCK to be JPA2 since DataNucleus 2.x uses that now2009-11-16T07:59:39Z2009-11-16T07:59:39ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Andy Jefferson resolved JDO-649.
<br>--------------------------------
<br><br> Resolution: Fixed
<br><br>SVN trunk fixes this
<br><div class='shrinkable-quote'><br>> Upgrade "persistence-api.jar" for use with TCK to be JPA2 since DataNucleus 2.x uses that now
<br>> ---------------------------------------------------------------------------------------------
<br>>
<br>> Key: JDO-649
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-649" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-649</a><br>> Project: JDO
<br>> Issue Type: Task
<br>> Components: tck2
<br>> Reporter: Andy Jefferson
<br>> Assignee: Andy Jefferson
<br>> Fix For: JDO 2 maintenance release 3
<br>>
<br>>
<br>> DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs" dependency. Was previously
<br>> <dependency>
<br>> <groupId>org.apache.geronimo.specs</groupId>
<br>> <artifactId>geronimo-jpa_3.0_spec</artifactId>
<br>> <version>1.0</version>
<br>> </dependency>
<br>> and should be
<br>> <dependency>
<br>> <groupId>org.apache.geronimo.specs</groupId>
<br>> <artifactId>geronimo-jpa_2.0_spec</artifactId>
<br>> <version>1.0-PFD2</version>
<br>> </dependency>
<br>> No idea why geronimo specs thinks JPA1 is "JPA 3.0" but anyway ...
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26374250[jira] Updated: (JDO-649) Upgrade "persistence.xml" for use with TCK to be JPA2 since DataNucleus 2.x uses that now2009-11-16T07:51:39Z2009-11-16T07:51:39ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Andy Jefferson updated JDO-649:
<br>-------------------------------
<br><br> Description:
<br>DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs" dependency. Was previously
<br><br><dependency>
<br> <groupId>org.apache.geronimo.specs</groupId>
<br> <artifactId>geronimo-jpa_3.0_spec</artifactId>
<br> <version>1.0</version>
<br></dependency>
<br><br>and should be
<br><br><dependency>
<br> <groupId>org.apache.geronimo.specs</groupId>
<br> <artifactId>geronimo-jpa_2.0_spec</artifactId>
<br> <version>1.0-PFD2</version>
<br></dependency>
<br><br>No idea why geronimo specs thinks JPA1 is "JPA 3.0" but anyway ...
<br><br> was:DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs" dependency
<br><br><div class='shrinkable-quote'><br>> Upgrade "persistence.xml" for use with TCK to be JPA2 since DataNucleus 2.x uses that now
<br>> -----------------------------------------------------------------------------------------
<br>>
<br>> Key: JDO-649
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-649" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-649</a><br>> Project: JDO
<br>> Issue Type: Task
<br>> Components: tck2
<br>> Reporter: Andy Jefferson
<br>> Assignee: Andy Jefferson
<br>> Fix For: JDO 2 maintenance release 3
<br>>
<br>>
<br>> DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs" dependency. Was previously
<br>> <dependency>
<br>> <groupId>org.apache.geronimo.specs</groupId>
<br>> <artifactId>geronimo-jpa_3.0_spec</artifactId>
<br>> <version>1.0</version>
<br>> </dependency>
<br>> and should be
<br>> <dependency>
<br>> <groupId>org.apache.geronimo.specs</groupId>
<br>> <artifactId>geronimo-jpa_2.0_spec</artifactId>
<br>> <version>1.0-PFD2</version>
<br>> </dependency>
<br>> No idea why geronimo specs thinks JPA1 is "JPA 3.0" but anyway ...
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26374252[jira] Updated: (JDO-649) Upgrade "persistence-api.jar" for use with TCK to be JPA2 since DataNucleus 2.x uses that now2009-11-16T07:51:39Z2009-11-16T07:51:39ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Andy Jefferson updated JDO-649:
<br>-------------------------------
<br><br> Summary: Upgrade "persistence-api.jar" for use with TCK to be JPA2 since DataNucleus 2.x uses that now (was: Upgrade "persistence.xml" for use with TCK to be JPA2 since DataNucleus 2.x uses that now)
<br><div class='shrinkable-quote'><br>> Upgrade "persistence-api.jar" for use with TCK to be JPA2 since DataNucleus 2.x uses that now
<br>> ---------------------------------------------------------------------------------------------
<br>>
<br>> Key: JDO-649
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-649" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-649</a><br>> Project: JDO
<br>> Issue Type: Task
<br>> Components: tck2
<br>> Reporter: Andy Jefferson
<br>> Assignee: Andy Jefferson
<br>> Fix For: JDO 2 maintenance release 3
<br>>
<br>>
<br>> DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs" dependency. Was previously
<br>> <dependency>
<br>> <groupId>org.apache.geronimo.specs</groupId>
<br>> <artifactId>geronimo-jpa_3.0_spec</artifactId>
<br>> <version>1.0</version>
<br>> </dependency>
<br>> and should be
<br>> <dependency>
<br>> <groupId>org.apache.geronimo.specs</groupId>
<br>> <artifactId>geronimo-jpa_2.0_spec</artifactId>
<br>> <version>1.0-PFD2</version>
<br>> </dependency>
<br>> No idea why geronimo specs thinks JPA1 is "JPA 3.0" but anyway ...
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26374215[jira] Created: (JDO-649) Upgrade "persistence.xml" for use with TCK to be JPA2 since DataNucleus 2.x uses that now2009-11-16T07:49:39Z2009-11-16T07:49:39ZJIRA jira@apache.orgUpgrade "persistence.xml" for use with TCK to be JPA2 since DataNucleus 2.x uses that now
<br>-----------------------------------------------------------------------------------------
<br><br> Key: JDO-649
<br> URL: <a href="https://issues.apache.org/jira/browse/JDO-649" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-649</a><br> Project: JDO
<br> Issue Type: Task
<br> Components: tck2
<br> Reporter: Andy Jefferson
<br> Assignee: Andy Jefferson
<br> Fix For: JDO 2 maintenance release 3
<br><br><br>DataNucleus builds against JPA2 specification now so need to upgrade the "geronimo-specs" dependency
<br><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26340621Minutes: JDO TCK Conference Call Friday, Nov 13 9 am PDT2009-11-13T09:51:18Z2009-11-13T09:51:18ZCraig L RussellAttendees: Michael Bouschen, Michelle Caisse, Craig Russell
<br><br>Agenda:
<br><br>1. Change JTA 1.1 dependency artifact id from "transaction-api" to
<br>"jta" <a href="https://issues.apache.org/jira/browse/JDO-644" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-644</a><br><br>Patch looks good. Ship it.
<br><br>2. Query timeout test <a href="https://issues.apache.org/jira/browse/JDO-623" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-623</a><br><br>Issues needing resolution: Should there be a documented option in case
<br>the JDO implementation or the underlying datastore doesn't support a
<br>query timeout? Does the query timeout apply to all "datastore query"
<br>operations including find by key, navigation, and loading lazy
<br>collections? If the datastore has the JDBC standard second resolution,
<br>and there is less than 1000 millis left in the timeout, what should be
<br>the timeout set on the datastore query statement? AI Michael write up
<br>issues with proposed solution.
<br><br>3. Question re Support for if-then-else in JDOQL
<br><br>This might make sense for a future release (it's probably too big to
<br>fit into 2.3). AI Michael take a look at what changes would be needed
<br>in the BNF, reply to the original email, and then discuss. The Java
<br>conditional expression maps to the SQL CASE ELSE END expression. More
<br>difficult for non-SQL datastores so it might involve an optional
<br>feature.
<br><br>4. Other issues
<br><br>none.
<br><br>Craig L Russell
<br>Architect, Sun Java Enterprise System <a href="http://db.apache.org/jdo" target="_top" rel="nofollow">http://db.apache.org/jdo</a><br>408 276-5638 mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26340621&i=0" target="_top" rel="nofollow">Craig.Russell@...</a>
<br>P.S. A good JDO? O, Gasp!
<br><br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (3K) <a href="http://old.nabble.com/attachment/26340621/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26330463[jira] Updated: (JDO-644) Change JTA 1.1 dependency artifact id from "transaction-api" to "jta"2009-11-12T18:52:39Z2009-11-12T18:52:39ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Michelle Caisse updated JDO-644:
<br>--------------------------------
<br><br> Attachment: jta-01-new.patch
<br><br>Per discussion at the last teleconference, propose using this new patch that modifies only api2/pom.xml, which is the only build file used by Maven 2. This should solve the problem with Maven 2 and avoid any issues for Maven 1 users.
<br><div class='shrinkable-quote'><br>> Change JTA 1.1 dependency artifact id from "transaction-api" to "jta"
<br>> ---------------------------------------------------------------------
<br>>
<br>> Key: JDO-644
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-644" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-644</a><br>> Project: JDO
<br>> Issue Type: Improvement
<br>> Components: api2, api2-legacy, core2, enhancer2, fostore2, model2, query2, runtime2, tck2, tck2-legacy, util2
<br>> Affects Versions: JDO 2 maintenance release 3
<br>> Reporter: Matthew T. Adams
<br>> Attachments: jta-01-new.patch, jta-01.patch
<br>>
<br>>
<br>> It appears that the Maven 2 artifact id for JTA 1.1 is "jta", not "transaction-api". The Maven 2 POM is here:
<br>> <a href="http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/transaction/jta/1.1/jta-1.1.pom" target="_top" rel="nofollow">http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/transaction/jta/1.1/jta-1.1.pom</a><br>> For Maven1, the Maven 1 artifact id is "transaction-api":
<br>> <a href="http://download.java.net/maven/1/javax.transaction/poms/transaction-api-1.1.pom" target="_top" rel="nofollow">http://download.java.net/maven/1/javax.transaction/poms/transaction-api-1.1.pom</a><br>> Since most users use Maven2, this should be updated to "jta" and we, the team producing JDO, should just manually install JTA 1.1 into our own local Maven 1 repository with the artifact id "jta", using the Maven 2. Without this, it is extremely annoying for users to have to work around this.
<br>> An alternative solution would be to upload to the Maven 1 central repo a copy of JTA 1.1 with artifact id "jta", but I don't how to do that.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26330392JDO TCK Conference Call Friday, Nov 13 9 am PDT2009-11-12T18:42:34Z2009-11-12T18:42:34ZMichelle Caisse-2Hi,
<br><br>We will have our regular meeting Friday, November 13 at 9 am PDT to
<br>discuss JDO TCK issues and status.
<br><br>Dial-in numbers are:
<br>Domestic (toll-free): 866 230-6968
<br>International (caller-paid): +1 213 787-0528
<br>Access code : 294-0479#
<br><br>Agenda:
<br><br>1. Change JTA 1.1 dependency artifact id from "transaction-api" to "jta"
<br><a href="https://issues.apache.org/jira/browse/JDO-644" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-644</a><br>2. Query timeout test <a href="https://issues.apache.org/jira/browse/JDO-623" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-623</a><br>3. Question re Support for if-then-else in JDOQL
<br>4. Other issues
<br><br>Action Items from weeks past:
<br><br>-- Michelle
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26299562Support for if-then-else in JDOQL2009-11-11T03:07:26Z2009-11-11T03:07:26ZTimo Westkämper-2Hello.
<br><br>I am implementing the shortcut form for if-then-else (x ? y : c) in
<br>Querydsl.
<br><br>Is there support for it in JDOQL? If not, could it be added?
<br><br>Br,
<br>Timo Westkämper.
<br><br>--
<br>Timo Westkämper <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26299562&i=0" target="_top" rel="nofollow">timo.westkamper@...</a>>
<br>Mysema Ltd, Vilhonkatu 5 A, 00100 Helsinki, Finland
<br>Mob. +358 (0)40 591 2172
<br>Internet: <a href="http://www.mysema.com" target="_top" rel="nofollow">http://www.mysema.com</a><br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26226452JDO TCK Conference Call Friday: CANCELLED2009-11-05T19:35:48Z2009-11-05T19:35:48ZMichelle Caisse-2Tomorrow's conference call is cancelled. We will meet again on Friday,
<br>November 13 at 9 am PST.
<br><br>-- Michelle
<br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26174770query timeout2009-11-02T20:29:10Z2009-11-02T20:29:10ZMichelle Caisse-2If the issue is support for JDBC setQueryTimeout, it appears that at
<br>least PostgreSQL lacks support. Here are links to discussions of the
<br>issue for a few databases.
<br><br>Oracle: supported, but timing issues can affect results
<br><a href="http://forums.oracle.com/forums/thread.jspa?threadID=550257" target="_top" rel="nofollow">http://forums.oracle.com/forums/thread.jspa?threadID=550257</a><br><br>PostgreSQL: apparently not supported
<br><a href="http://archives.postgresql.org/pgsql-jdbc/2008-01/msg00089.php" target="_top" rel="nofollow">http://archives.postgresql.org/pgsql-jdbc/2008-01/msg00089.php</a><br><br>Derby: supported
<br><a href="http://old.nabble.com/cancel-a-running-query--td19903183.html" target="_top" rel="nofollow">http://old.nabble.com/cancel-a-running-query--td19903183.html</a><br><br>-- Michelle
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26133479Re: Minutes: JDO TCK Conference Call Friday, Oct 30 9 am PDT2009-10-30T09:52:50Z2009-10-30T09:52:50ZMichael Bouschen-2Hi,
<br><br>I'm sorry, I missed the call today. I forgot that the conference call is
<br>one hour earlier for me, because Germany already switched back from
<br>daylight saving time. I checked my email to prepare for the conference
<br>call and found the minutes :-).
<br><br>Regards Michael
<br><div class='shrinkable-quote'><br>> Attendees: Michelle Caisse, Craig Russell
<br>>
<br>> Agenda:
<br>>
<br>> 1. Change JTA 1.1 dependency artifact id from "transaction-api" to
<br>> "jta" <a href="https://issues.apache.org/jira/browse/JDO-644" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-644</a><br>>
<br>> It seems that there is a problem with the patch. Since the only
<br>> artifact affected for maven 2 users is the api2/pom.xml, and maven 1
<br>> is used for everything else, perhaps simply updating the api2 pom
<br>> would be best. AI Michelle test just updating api2 pom and update the
<br>> JIRA.
<br>>
<br>> 2. Query timeout test <a href="https://issues.apache.org/jira/browse/JDO-623" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-623</a><br>>
<br>> Still open AI's to finish the discussion of what exactly query timeout
<br>> means, and whether it's optional.
<br>>
<br>> 3. Other issues
<br>>
<br>> Action Items from weeks past:
<br>>
<br>> 16 Oct 08 AI Michelle: Investigate query timeouts as they apply to SQL
<br>> standard datastores.
<br>>
<br>> Craig L Russell
<br>> Architect, Sun Java Enterprise System <a href="http://db.apache.org/jdo" target="_top" rel="nofollow">http://db.apache.org/jdo</a><br>> 408 276-5638 mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26133479&i=0" target="_top" rel="nofollow">Craig.Russell@...</a>
<br>> P.S. A good JDO? O, Gasp!
<br>>
</div><br><br>--
<br>*Michael Bouschen*
<br>*Prokurist*
<br><br>akquinet tech@spree GmbH
<br>Bülowstr. 66, D-10783 Berlin
<br><br>Fon: +49 30 235 520-33
<br>Fax: +49 30 217 520-12
<br>Email: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26133479&i=1" target="_top" rel="nofollow">michael.bouschen@...</a>
<br>Url: www.akquinet.de <<a href="http://www.akquinet.de" target="_top" rel="nofollow">http://www.akquinet.de</a>>
<br><br>akquinet tech@spree GmbH, Berlin
<br>Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
<br>Amtsgericht Berlin-Charlottenburg HRB 86780 B
<br>USt.-Id. Nr.: DE 225 964 680
<br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26133264Minutes: JDO TCK Conference Call Friday, Oct 30 9 am PDT2009-10-30T09:37:59Z2009-10-30T09:37:59ZCraig L RussellAttendees: Michelle Caisse, Craig Russell
<br><br>Agenda:
<br><br>1. Change JTA 1.1 dependency artifact id from "transaction-api" to
<br>"jta" <a href="https://issues.apache.org/jira/browse/JDO-644" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-644</a><br><br>It seems that there is a problem with the patch. Since the only
<br>artifact affected for maven 2 users is the api2/pom.xml, and maven 1
<br>is used for everything else, perhaps simply updating the api2 pom
<br>would be best. AI Michelle test just updating api2 pom and update the
<br>JIRA.
<br><br>2. Query timeout test <a href="https://issues.apache.org/jira/browse/JDO-623" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-623</a><br><br>Still open AI's to finish the discussion of what exactly query timeout
<br>means, and whether it's optional.
<br><br>3. Other issues
<br><br>Action Items from weeks past:
<br><br>16 Oct 08 AI Michelle: Investigate query timeouts as they apply to SQL
<br>standard datastores.
<br><br>Craig L Russell
<br>Architect, Sun Java Enterprise System <a href="http://db.apache.org/jdo" target="_top" rel="nofollow">http://db.apache.org/jdo</a><br>408 276-5638 mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26133264&i=0" target="_top" rel="nofollow">Craig.Russell@...</a>
<br>P.S. A good JDO? O, Gasp!
<br><br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (3K) <a href="http://old.nabble.com/attachment/26133264/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26130180JDO TCK Conference Call Friday, Oct 30 9 am PDT NOTE TIME CHANGE2009-10-30T06:32:21Z2009-10-30T06:32:21ZMichelle Caisse-2Hi,
<br><br>We will have our regular meeting Friday, October 30 at 9 am PDT to
<br>discuss JDO TCK issues and status.
<br><br>NOTE THAT THE U.S. IS STILL ON DAYLIGHT SAVINGS TIME TODAY!
<br><br>Dial-in numbers are:
<br>Domestic (toll-free): 866 230-6968
<br>International (caller-paid): +1 213 787-0528
<br>Access code : 294-0479#
<br><br>Agenda:
<br><br>1. Change JTA 1.1 dependency artifact id from "transaction-api" to "jta"
<br><a href="https://issues.apache.org/jira/browse/JDO-644" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-644</a><br>2. Query timeout test <a href="https://issues.apache.org/jira/browse/JDO-623" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-623</a><br>3. Other issues
<br><br>Action Items from weeks past:
<br><br>16 Oct 08 AI Michelle: Investigate query timeouts as they apply to SQL
<br>standard datastores.
<br><br>-- Michelle
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26044197[jira] Commented: (JDO-644) Change JTA 1.1 dependency artifact id from "transaction-api" to "jta"2009-10-24T17:02:59Z2009-10-24T17:02:59ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769738#action_12769738" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769738#action_12769738</a> ]
<br><br>Michelle Caisse commented on JDO-644:
<br>-------------------------------------
<br><br>Since the TCK can only be run with Maven 1, can we leave tck2/project.xml as is?
<br><br>With the patch installed I get enhancer errors on running the TCK, whereas the api2 project builds without error.
<br><br>16:36:40,468 (main) ERROR [DataNucleus.MetaData] - Class "org.apache.jdo.tck.pc.companyListWithoutJoin.CompanyModelReader" was not found in the CLASSPATH. Please check your specification and your CLASSPATH.
<br>org.datanucleus.exceptions.ClassNotResolvedException: Class "org.apache.jdo.tck.pc.companyListWithoutJoin.CompanyModelReader" was not found in the CLASSPATH. Please check your specification and your CLASSPATH.
<br> at org.datanucleus.JDOClassLoaderResolver.classForName(JDOClassLoaderResolver.java:250)
<br> at org.datanucleus.JDOClassLoaderResolver.classForName(JDOClassLoaderResolver.java:415)
<br> at org.datanucleus.metadata.MetaDataManager.loadClasses(MetaDataManager.java:436)
<br> at org.datanucleus.enhancer.DataNucleusEnhancer.getFileMetadataForInput(DataNucleusEnhancer.java:703)
<br> at org.datanucleus.enhancer.DataNucleusEnhancer.enhance(DataNucleusEnhancer.java:551)
<br> at org.datanucleus.jdo.JDODataNucleusEnhancer.enhance(JDODataNucleusEnhancer.java:126)
<br> at javax.jdo.Enhancer.run(Enhancer.java:196)
<br> at javax.jdo.Enhancer.main(Enhancer.java:130)
<br><br>for:
<br>org.apache.jdo.tck.pc.mylib.MylibReader
<br>org.apache.jdo.tck.pc.companyListWithoutJoin.CompanyModelReader
<br>org.apache.jdo.tck.pc.companyMapWithoutJoin.CompanyModelReader
<br>org.apache.jdo.tck.pc.company.CompanyModelReader
<br>org.apache.jdo.tck.pc.order.OrderModelReader
<br><br>There are also test errors, including the runonce test.
<br><br>I haven't tried to upload jta 1.1, but why would it be found for api2 and not tck2? The only possibly relevant difference I can see is that api2 has a pom.xml and tck2 does not.
<br><br><br><br><div class='shrinkable-quote'><br>> Change JTA 1.1 dependency artifact id from "transaction-api" to "jta"
<br>> ---------------------------------------------------------------------
<br>>
<br>> Key: JDO-644
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-644" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-644</a><br>> Project: JDO
<br>> Issue Type: Improvement
<br>> Components: api2, api2-legacy, core2, enhancer2, fostore2, model2, query2, runtime2, tck2, tck2-legacy, util2
<br>> Affects Versions: JDO 2 maintenance release 3
<br>> Reporter: Matthew T. Adams
<br>> Attachments: jta-01.patch
<br>>
<br>>
<br>> It appears that the Maven 2 artifact id for JTA 1.1 is "jta", not "transaction-api". The Maven 2 POM is here:
<br>> <a href="http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/transaction/jta/1.1/jta-1.1.pom" target="_top" rel="nofollow">http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/transaction/jta/1.1/jta-1.1.pom</a><br>> For Maven1, the Maven 1 artifact id is "transaction-api":
<br>> <a href="http://download.java.net/maven/1/javax.transaction/poms/transaction-api-1.1.pom" target="_top" rel="nofollow">http://download.java.net/maven/1/javax.transaction/poms/transaction-api-1.1.pom</a><br>> Since most users use Maven2, this should be updated to "jta" and we, the team producing JDO, should just manually install JTA 1.1 into our own local Maven 1 repository with the artifact id "jta", using the Maven 2. Without this, it is extremely annoying for users to have to work around this.
<br>> An alternative solution would be to upload to the Maven 1 central repo a copy of JTA 1.1 with artifact id "jta", but I don't how to do that.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26042393[jira] Resolved: (JDO-639) tck enhancement should make use of feature to enhance an entire directory2009-10-24T12:48:59Z2009-10-24T12:48:59ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Michelle Caisse resolved JDO-639.
<br>---------------------------------
<br><br> Resolution: Fixed
<br><br>Complete with revision 829438
<br><div class='shrinkable-quote'><br>> tck enhancement should make use of feature to enhance an entire directory
<br>> -------------------------------------------------------------------------
<br>>
<br>> Key: JDO-639
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-639" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-639</a><br>> Project: JDO
<br>> Issue Type: Improvement
<br>> Components: tck2
<br>> Affects Versions: JDO 2 maintenance release 2
<br>> Reporter: Michael Bouschen
<br>> Assignee: Michelle Caisse
<br>> Attachments: enhance.txt, jdo-639.txt
<br>>
<br>>
<br>> The current enhancer call as part of the runtck goal takes a list of .jdo files as an argument (see property jdo.tck.jdometadata.files in project.properties and maven.xml). The new enhancer invocation API allows to enhance all files of a given directory. We should investigate to make use of this feature in order to get rid of listing all the .jdo in the property jdo.tck.jdometadata.files.
<br>> There is a similar issue with the properties jdo.tck.pcclasses.sources and jdo.tck.pcclasses.files:
<br>> - Property jdo.tck.pcclasses.sources is used when checking whether (re)enhancing is required. Maybe a pattern
<br>> org/apache/jdo/tck/api/**/*.java, org/apache/jdo/tck/pc/**/*.java
<br>> can be used instead of listing all the persistent capable classes explicitly.
<br>> - Property jdo.tck.pcclasses.files is used when copying the class file into the identitytype specific subdirectories before running the enhancer. Maybe a similar pattern could replace the list of class files.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:old.nabble.com,2006:post-26041719[jira] Commented: (JDO-639) tck enhancement should make use of feature to enhance an entire directory2009-10-24T11:25:59Z2009-10-24T11:25:59ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769695#action_12769695" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769695#action_12769695</a> ]
<br><br>Craig Russell commented on JDO-639:
<br>-----------------------------------
<br><br>> The variables jdo.tck.paclasses.sources and jdo.tck.pcclasses.sources are always used together (as a union of the two sets). Same for *.files. Would it be a good idea now to further simplify things by using only one variable (pcclasses) and note in a comment that it also contains paclasses?
<br><br>Since they are always used together, I see no down side in combining them.
<br><div class='shrinkable-quote'><br>> tck enhancement should make use of feature to enhance an entire directory
<br>> -------------------------------------------------------------------------
<br>>
<br>> Key: JDO-639
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-639" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-639</a><br>> Project: JDO
<br>> Issue Type: Improvement
<br>> Components: tck2
<br>> Affects Versions: JDO 2 maintenance release 2
<br>> Reporter: Michael Bouschen
<br>> Assignee: Michelle Caisse
<br>> Attachments: enhance.txt, jdo-639.txt
<br>>
<br>>
<br>> The current enhancer call as part of the runtck goal takes a list of .jdo files as an argument (see property jdo.tck.jdometadata.files in project.properties and maven.xml). The new enhancer invocation API allows to enhance all files of a given directory. We should investigate to make use of this feature in order to get rid of listing all the .jdo in the property jdo.tck.jdometadata.files.
<br>> There is a similar issue with the properties jdo.tck.pcclasses.sources and jdo.tck.pcclasses.files:
<br>> - Property jdo.tck.pcclasses.sources is used when checking whether (re)enhancing is required. Maybe a pattern
<br>> org/apache/jdo/tck/api/**/*.java, org/apache/jdo/tck/pc/**/*.java
<br>> can be used instead of listing all the persistent capable classes explicitly.
<br>> - Property jdo.tck.pcclasses.files is used when copying the class file into the identitytype specific subdirectories before running the enhancer. Maybe a similar pattern could replace the list of class files.
</div><br>--
<br>This message is automatically generated by JIRA.
<br>-
<br>You can reply to this email to add a comment to the issue online.
<br><br><p>From forum: <a href="http://old.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>