Minutes: JDO TCK Conference Call Friday October 19, 9 am Pacific Time
Attendees: Michael Bouschen, Craig Russell Agenda: 1. News on JDO-717 copyjdorijars does not cleanup target directory https://issues.apache.org/jira/browse/JDO-717? Assign to Matthew for resolution. 2. News on spec update? JDO-678 updates are done. Chapter 12 Chapter 14 changes are complete. JDO-689, JDO-690, and JDO-692 will be looked at and resolved together. The last unresolved issue will then be JDO-702 for spec updates. 3. Other issues Need to check the specification for assertions for new test cases that were added. We should review all resolved issues and make sure that new tests have assertions that match the specification. Action Items from weeks past: [Sep 7 2012] AI Everybody We need to look at adding assertions into the specification and tck test cases. [Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about JDOHelper methods. [Aug 17 2012] AI Craig comment on JIRA JDO-589 Autocommit or nontransactional action [Jul 20 2012] AI Michelle: take a look into adding JDO social links to db.apache.org/jdo. [Sep 23 2011] AI Michael document when changing dependencies (to DataNucleus) it's necessary to rebuild the exectck project before running tck. 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] [Assigned] (JDO-717) copyjdorijars does not cleanup target directory
[ https://issues.apache.org/jira/browse/JDO-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen reassigned JDO-717: Assignee: Matthew T. Adams (was: Michael Bouschen) > copyjdorijars does not cleanup target directory > --- > > Key: JDO-717 > URL: https://issues.apache.org/jira/browse/JDO-717 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3 update 1 (3.0.1) >Reporter: Michael Bouschen >Assignee: Matthew T. Adams > Fix For: JDO 3 maintenance release 1 (3.1) > > > The submodule copyjdorijars does not cleanup the target directory before > copying the jdori artifacts. This may lead to multiple versions of the jdori > in the target directory when running the tck. > An alternative solution is adding the jdori dependencies as part of a jdori > profile such that they do not get added to the CLASSPATH when running an iut. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JDO-667) Extend PersistenceManageFactory to return all known entity classes
[ https://issues.apache.org/jira/browse/JDO-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell resolved JDO-667. - Resolution: Fixed > Extend PersistenceManageFactory to return all known entity classes > -- > > Key: JDO-667 > URL: https://issues.apache.org/jira/browse/JDO-667 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Affects Versions: JDO 3 (3.0) >Reporter: Marco >Assignee: Craig L Russell > Fix For: JDO 3 maintenance release 1 (3.1) > > Attachments: JDO-667-api.patch, JDO-667-tck.patch > > > JDO 3 now has the ability to declare meta-data programmatically. Part of this > feature is the ability to ask the PersistenceManagerFactory via the method > getMetadata(java.lang.String) for the meta-data of one single class. But > there is no way to list all known classes. > I therefore kindly ask for a new method in PersistenceManagerFactory like > this: > Collection getClassesWithMetadata(); > Btw., this is Andy's suggestion posted here: > http://www.datanucleus.org/servlet/forum/viewthread_thread,6379#33224 > I'd greatly appreciate, if this method became a part of JDO 3.1. > Edit 1: I just saw the various overloaded methods getManagedObjects(...) in > PersistenceManager - maybe the alternative method name "getManagedClasses()" > would be more consistent? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JDO-674) Support a way of defining inheritance strategy that results in a table per class with the table containing columns for all fields in the class (inc superclasses)
[ https://issues.apache.org/jira/browse/JDO-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell resolved JDO-674. - Resolution: Fixed > Support a way of defining inheritance strategy that results in a table per > class with the table containing columns for all fields in the class (inc > superclasses) > - > > Key: JDO-674 > URL: https://issues.apache.org/jira/browse/JDO-674 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Affects Versions: JDO 3 (3.0) >Reporter: Andy Jefferson >Assignee: Craig L Russell > Fix For: JDO 3 maintenance release 1 (3.1) > > Attachments: JDO-674.patch > > > JPA provides an inheritance strategy "TABLE PER CLASS". In JPA this is > defined in the root of an inheritance tree and implies that all classes in > the inheritance tree have their own table that contains columns for all > fields (inc fields in superclasses). There is currently no way to achieve > this with JDO's strategy specification capability. > Propose we provide one of the following > 1. Just have a strategy "complete-table" specified in the root of the > inheritance hierarchy that implies the same as the JPA situation. This is the > simplest to define. > 2. Have a strategy "complete-table" that can be specified on any class with > the result that this class has a table containing columns for all fields (inc > superclasses). There are difficulties in defining what happens in the case of > a subclass - can it take any of the standard inheritance strategy settings ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JDO-660) Ability to specify positioning of field 'column(s)' in datastore "table"
[ https://issues.apache.org/jira/browse/JDO-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell resolved JDO-660. - Resolution: Fixed > Ability to specify positioning of field 'column(s)' in datastore "table" > > > Key: JDO-660 > URL: https://issues.apache.org/jira/browse/JDO-660 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson >Assignee: Craig L Russell > Fix For: JDO 3 maintenance release 1 (3.1) > > Attachments: column_position.patch > > > With an RDBMS datastore, when generating the schema, it is desirable to be > able to specify the positioning of the column(s) of a field in the generated > table. > With spreadsheet documents, it is critical to be able to define which column > number is used for a particular field. > With other datastores it is also likely desirable. > To achieve this I propose adding an attribute to the XML called > "position". Similarly for the @Column annotation. > This can take integer values with 0-origin. > Complications : > 1. how this is handled when we have inheritance. If a root class has > subclass-table inheritance, then those fields are persisted into the tables > of all subclasses, and we may want to override the positions for those > individually - to that end the user can override the metadata of the > superclass fields. > 2. anything else ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JDO-662) Extend "sequence" metadata to allow specification of start and allocationSize
[ https://issues.apache.org/jira/browse/JDO-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig L Russell resolved JDO-662. - Resolution: Fixed > Extend "sequence" metadata to allow specification of start and allocationSize > - > > Key: JDO-662 > URL: https://issues.apache.org/jira/browse/JDO-662 > Project: JDO > Issue Type: Improvement > Components: api, specification, tck >Reporter: Andy Jefferson >Assignee: Craig L Russell > Fix For: JDO 3 maintenance release 1 (3.1) > > Attachments: JDO-662.patch > > > While the user can define to use a datastore sequence currently, with a > particular name, they cannot define the allocation size and start point of > that sequence to be used when creating it (if the implementation is creating > it). Would make sense to allow these settings in the metadata -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JDO-678) Ability to set properties on PersistenceManager
[ https://issues.apache.org/jira/browse/JDO-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480074#comment-13480074 ] Craig L Russell commented on JDO-678: - Specification update: 12.19 Property Management The operation of a PersistenceManager is partly governed by the settings of various properties, which have been documented in earler sections. These properties are inherited from the PersistenceManagerFactory whence the PersistenceManager was obtained. The properties can be set by methods such as setNontransactionalRead. Some properties are not standardized but are implementation-defined. These non-standard properties can only be set via the setProperty method. void setProperty(String name, Object value); Set the property named name to the value value. If a vendor-specific property is not recognized, it is silently ignored. If the value for the property is not supported by the implementation, a JDOUserException is thrown. Map getProperties(); Return a map of String, Object with the properties and values currently in effect. Changing the values in the map will not affect the properties in the PersistenceManager. Set getSupportedProperties(); Return a set of properties supported by this PersistenceManager. > Ability to set properties on PersistenceManager > --- > > Key: JDO-678 > URL: https://issues.apache.org/jira/browse/JDO-678 > Project: JDO > Issue Type: Improvement > Components: api, specification, tck >Affects Versions: JDO 3 (3.0) >Reporter: Andy Jefferson >Assignee: Craig L Russell > Fix For: JDO 3 maintenance release 1 (3.1) > > Attachments: jdo-678.patch > > > It would be desirable to be able to set properties on the PersistenceManager, > so as to be able to configure/change behaviour for a PM. Currently the PM is > generated with particular configuration (from the PMF) and allows specific > options to be set. But what about vendor extensions ? Having a general > setProperty/getProperty/getSupportedProperties would be useful, and could > also encompass the existing detachAllOnCommit, IgnoreCache, etc settings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
