Re: JDO TCK Conference Call Friday, Mar 18, 9 am Pacific Time
Sorry, can't make it today... On Thu, Mar 17, 2011 at 11:41 PM, mcai...@sonic.net wrote: Hi, We will have our regular meeting Friday, March 18, at 9 am Pacific Time to discuss JDO TCK issues and status. Dial-in numbers are: US Toll free: 866 682-4770 Germany Frankfurt 06916106 Germany Toll free: 08006648515 (Other countries by request) To place the call: 1. Call the toll free number. 2. Enter the conference number 939-3689# 3. Enter the security code # Agenda: 1. TCK State Transitions test 2. Ability to mark a class as read-only - https://issues.apache.org/jira/browse/JDO-677 [1] 3. Other issues Action Items from weeks past: [Feb 25 2011] AI Michael, Craig, other volunteers: Look at Typesafe ... query capability for JDOQL https://issues.apache.org/jira/browse/JDO-652 [2] -- Michelle Links: -- [1] http://webmail.sonic.net/parse.php?redirect=https://issues.apache.org/jira/browse/JDO-677 [2] http://webmail.sonic.net/parse.php?redirect=https://issues.apache.org/jira/browse/JDO-652 -- mailto:matt...@matthewadams.me skype:matthewadams12 yahoo:matthewadams aol:matthewadams12 google-talk:matthewadam...@gmail.com msn:matt...@matthewadams.me http://matthewadams.me http://www.linkedin.com/in/matthewadams
Minutes: JDO TCK Conference Call Friday, Mar 18, 9 am Pacific Time
Attendees: Michelle Caisse, Craig Russell Agenda: 1. TCK State Transitions test: the way the test creates e.g. persistent dirty instances is to get a random persistent instance from the database, make it hollow, and then write the field. The specification states A hollow instance transitions to persistent- dirty if a change is made to any managed field. Does this apply if the value written is the same as the current value? It's deliberately vague. The test could be improved by implementing the getPersistentDirtyInstance to write the value of the static field into the persistent field instead of the value 23. There are 50 instances created at the beginning of the test because at the time the test is run, you don't know how many instances are needed. It depends on the features supported by the iut. Patches welcome. 2. Ability to mark a class as read-only - https://issues.apache.org/jira/browse/JDO-677 Nothing in the specification calls for writing to the database at the time the field is changed, so the checking probably should be done at flush/commit, even for datastore transactions. 3. Other issues Action Items from weeks past: [Feb 25 2011] AI Michael, Craig, other volunteers: Look at Typesafe ... query capability for JDOQL https://issues.apache.org/jira/browse/JDO-652 Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp!
[jira] Commented: (JDO-677) Ability to mark a class as read-only
[ https://issues.apache.org/jira/browse/JDO-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008507#comment-13008507 ] Craig L Russell commented on JDO-677: - Nothing in the specification calls for writing to the database at the time the field is changed, so the checking probably should be done at flush/commit, even for datastore transactions. This is different from a class that knows that it is read-only, or might be configured to be read-only at the modeling level. In this case, mutators should throw an exception. For an example of this kind of behavior, see java.util.Collections unmodifiableCollection method that returns a read-only instance. Ability to mark a class as read-only Key: JDO-677 URL: https://issues.apache.org/jira/browse/JDO-677 Project: JDO Issue Type: New Feature Components: api, specification, tck Reporter: Andy Jefferson While JDO already allows a datastore to be marked as read-only (javax.jdo.option.ReadOnly), it would be desirable to extend this down to class-level. To achieve this we could add an (boolean) attribute read-only at class level to metadata. The same behaviour defined in the spec as for datastore-level would apply at class-level when a class is marked with this attribute as true -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
