tag:www.nabble.com,2006:forum-23350Nabble - Apache JDO2008-08-21T16:11:00Z<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:www.nabble.com,2006:post-19098740JDO TCK Conference Call Friday, Aug 22, 9 am PDT2008-08-21T16:11:00Z2008-08-21T16:11:00ZMichelle CaisseHi,
<br><br>We will have our regular meeting Friday, Aug 22 at 9 am PDT to discuss
<br>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. api2-legacy: maintain or dump?
<br>2. JDO 2.2 release timing
<br>3. getPMF tests (<a href="http://issues.apache.org/jira/browse/JDO-582" target="_top" rel="nofollow">http://issues.apache.org/jira/browse/JDO-582</a>)
<br>4. Other issues
<br><br>Action Items from weeks past:
<br><br>[Feb 1 2008] AI Matthew see what would be needed to update the PMF
<br>contract to support ServiceLoader.
<br><br>[Nov 30 2007] AI Christiaan propose more details on Update/copy by query
<br>for post-JDO 2.1.
<br><br>[May 25 2007] AI everyone download the Grails demo from grails.org and
<br>check it out. Also look at Grails/Groovy ExpandoMetaClass that has the
<br>magic to avoid reflection and enhancement.
<br><br>[May 25 2007] AI Matthew Adams prepare a proposal with just the basics
<br>of schema synchronization with jdo and orm metadata.
<br><br>[Aug 11 2006] AI Craig propose some semantics for behavior if user tries
<br>to add to a list where the ordering element is incorrect.
<br><br>[Sep 2 2005] AI: To recruit members: Articles on TheServerSide
<br>directing attention to the site. T-shirts. AI: Craig write a
<br>ServerSide article.
<br><br>-- Michelle
<br><br><br><p>From forum: <a href="http://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19097963Re: svn commit: r687454 - /db/jdo/trunk/tck2/maven.xml2008-08-21T15:11:58Z2008-08-21T15:11:58ZCraig L RussellOops, the comment should read:
<br><br>> + <echo>The top-level directory name must terminate in
<br>> "jdo".</echo>
<br>> + <echo>Please rename your directory to "jdo" or
<br>> "XXXjdo".</echo>
<br>> + <echo>Otherwise the dist directory will be incorrectly
<br>> named.</echo>
<br><br>Craig
<br>On Aug 20, 2008, at 1:44 PM, <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19097963&i=0" target="_top" rel="nofollow">mcaisse@...</a> wrote:
<br><div class='shrinkable-quote'><div class='shrinkable-quote'><br>> Author: mcaisse
<br>> Date: Wed Aug 20 13:44:59 2008
<br>> New Revision: 687454
<br>>
<br>> URL: <a href="http://svn.apache.org/viewvc?rev=687454&view=rev" target="_top" rel="nofollow">http://svn.apache.org/viewvc?rev=687454&view=rev</a><br>> Log:
<br>> JDO-603 Catch bad directory name and report problem.
<br>>
<br>> Modified:
<br>> db/jdo/trunk/tck2/maven.xml
<br>>
<br>> Modified: db/jdo/trunk/tck2/maven.xml
<br>> URL: <a href="http://svn.apache.org/viewvc/db/jdo/trunk/tck2/maven.xml?rev=687454&r1=687453&r2=687454&view=diff" target="_top" rel="nofollow">http://svn.apache.org/viewvc/db/jdo/trunk/tck2/maven.xml?rev=687454&r1=687453&r2=687454&view=diff</a><br>> =
<br>> =
<br>> =
<br>> =
<br>> =
<br>> =
<br>> =
<br>> =
<br>> ======================================================================
<br>> --- db/jdo/trunk/tck2/maven.xml (original)
<br>> +++ db/jdo/trunk/tck2/maven.xml Wed Aug 20 13:44:59 2008
<br>> @@ -123,6 +123,8 @@
<br>> <j:set var="nullval" value=""/>
<br>> <j:set var="true" value="true"/>
<br>> <j:set var="false" value="false"/>
<br>> + <j:set var="slashval" value="/"/>
<br>> + <j:set var="backslashval" value="\"/>
<br>>
<br>> <j:set var="cfglist" value="${jdo.tck.cfglist}"/>
<br>> <j:if test="${cfglist == null}">
<br>> @@ -829,7 +831,16 @@
<br>>
<br>> <goal name="dist">
<br>> <!-- Just do a source distribution for tck20. -->
<br>> - <attainGoal name="dist:build-src"/>
<br>> + <j:if test="${basedir.lastIndexOf('jdo') ==
<br>> basedir.lastIndexOf('jdo\')
<br>> + || basedir.lastIndexOf('jdo') ==
<br>> basedir.lastIndexOf('jdo/')
<br>> + }">
<br>> + <attainGoal name="dist:build-src"/>
<br>> + </j:if>
<br>> + <j:else>
<br>> + <echo>The top-level directory name must terminate in
<br>> "jdo".</echo>
<br>> + <echo>Please rename your directory to "jdo" or
<br>> "jdoXXX".</echo>
<br>> + <echo>Otherwise the dist directory will be incorrectly
<br>> named.</echo>
<br>> + </j:else>
<br>> </goal>
<br>>
<br>> <preGoal name="dist:build-src">
<br>>
<br>>
</div></div>Craig L Russell
<br>Architect, Sun Java Enterprise System <a href="http://java.sun.com/products/jdo" target="_top" rel="nofollow">http://java.sun.com/products/jdo</a><br>408 276-5638 mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19097963&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://www.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (3K) <a href="http://www.nabble.com/attachment/19097963/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19089577Re: Updating datastore with transient instance2008-08-21T07:11:06Z2008-08-21T07:11:06ZJoerg von Frantzius-2Hi,
<br><br>the use-case sounds very reasonable to me, e.g. when the implementation
<br>of a web-service sends out a serialized persistent object, receives back
<br>the object with changes, and now needs to apply the changes to the
<br>database.
<br><br>Since makePersistent() is handling attaching so far, this could be the
<br>place to transition such an object from transient to persistent-dirty
<br>(with all fields marked dirty). Maybe an exception should be thrown when
<br>there already is a persistent-dirty object with the same id managed by
<br>the same PM. Since that would mean change of behaviour (somebody might
<br>rely on inserting new objects when calling makePersistent() on transient
<br>instances that have an id value), there probably should be an additional
<br>setMergeOnMakePersistent(boolean) or something like that, defaulting to
<br>the old behaviour.
<br><br>This would only work for application-identity. For datastore-identity,
<br>some new method(s) would be required to determine the objects' ids, as
<br>Pavel suggested.
<br><br>Regards,
<br>Jörg
<br><br>Pavel wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> This email is a continuation of discussion started at
<br>> <a href="http://www.jpox.org/servlet/forum/viewthread?thread=4893&lastpage=yes" target="_top" rel="nofollow">http://www.jpox.org/servlet/forum/viewthread?thread=4893&lastpage=yes</a> .
<br>>
<br>> Quick summary is that there is a number of [I believe fairly strong] cases
<br>> where application deals with transient objects which somehow correspond to
<br>> already persisted objects.
<br>>
<br>> These instances have updated state in there, but persisting that state takes
<br>> extra code and datastore hits, just to preload persistent counterpart and
<br>> copy properties.
<br>>
<br>> My question is whether it is possible and makes sense for JDO to support
<br>> "attachment" of transient objects, so that
<br>> a) all the steps required for such "attachment" become duty of JDO
<br>> implementation, not client code and
<br>> b) reads before update are optimized (e.g. one read for collection) or
<br>> eliminated at all.
<br>>
<br>> Code-wise I imagine methods like
<br>>
<br>> // Application identity
<br>> <T> T attachTransient(T instanceWithAppIdentity);
<br>> <T> Collection<T> attachTransientAll(Collection<T>
<br>> instancesWithAppIdentity);
<br>>
<br>> // Datastore identity - client code provides id explicitly to let JDO
<br>> identify persistent counterpart
<br>> <T> T attachTransient(T instanceWithDSIdentity, Object id);
<br>> <T> Map<Object, T> attachTransientAll(Map<Object, T>
<br>> instancesWithDSIdentity); // Map is {id => instance}
<br>>
<br>> What do you think?
<br>>
<br>> Thanks,
<br>> Pavel
<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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19089576Re: Updating datastore with transient instance2008-08-21T07:11:04Z2008-08-21T07:11:04ZJoerg von Frantzius-2Hi,
<br><br>the use-case sounds very reasonable to me, e.g. when the implementation
<br>of a web-service sends out a serialized persistent object, receives back
<br>the object with changes, and now needs to apply the changes to the
<br>database.
<br><br>Since makePersistent() is handling attaching so far, this could be the
<br>place to transition such an object from transient to persistent-dirty
<br>(with all fields marked dirty). Maybe an exception should be thrown when
<br>there already is a persistent-dirty object with the same id managed by
<br>the same PM. Since that would mean change of behaviour (somebody might
<br>rely on inserting new objects when calling makePersistent() on transient
<br>instances that have an id value), there probably should be an additional
<br>setMergeOnMakePersistent(boolean) or something like that, defaulting to
<br>the old behaviour.
<br><br>This would only work for application-identity. For datastore-identity,
<br>some new method(s) would be required to determine the objects' ids, as
<br>Pavel suggested.
<br><br>Regards,
<br>Jörg
<br><br>Pavel wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> This email is a continuation of discussion started at
<br>> <a href="http://www.jpox.org/servlet/forum/viewthread?thread=4893&lastpage=yes" target="_top" rel="nofollow">http://www.jpox.org/servlet/forum/viewthread?thread=4893&lastpage=yes</a> .
<br>>
<br>> Quick summary is that there is a number of [I believe fairly strong] cases
<br>> where application deals with transient objects which somehow correspond to
<br>> already persisted objects.
<br>>
<br>> These instances have updated state in there, but persisting that state takes
<br>> extra code and datastore hits, just to preload persistent counterpart and
<br>> copy properties.
<br>>
<br>> My question is whether it is possible and makes sense for JDO to support
<br>> "attachment" of transient objects, so that
<br>> a) all the steps required for such "attachment" become duty of JDO
<br>> implementation, not client code and
<br>> b) reads before update are optimized (e.g. one read for collection) or
<br>> eliminated at all.
<br>>
<br>> Code-wise I imagine methods like
<br>>
<br>> // Application identity
<br>> <T> T attachTransient(T instanceWithAppIdentity);
<br>> <T> Collection<T> attachTransientAll(Collection<T>
<br>> instancesWithAppIdentity);
<br>>
<br>> // Datastore identity - client code provides id explicitly to let JDO
<br>> identify persistent counterpart
<br>> <T> T attachTransient(T instanceWithDSIdentity, Object id);
<br>> <T> Map<Object, T> attachTransientAll(Map<Object, T>
<br>> instancesWithDSIdentity); // Map is {id => instance}
<br>>
<br>> What do you think?
<br>>
<br>> Thanks,
<br>> Pavel
<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://www.nabble.com/JDO---User-f23352.html" embed="fixTarget[23352]" target="_top" >JDO - User</a></p>tag:www.nabble.com,2006:post-19078293[jira] Created: (JDO-606) jdo2-api maven2 pom missing for 2.2-SNAPSHOT2008-08-20T14:20:44Z2008-08-20T14:20:44ZJIRA jira@apache.orgjdo2-api maven2 pom missing for 2.2-SNAPSHOT
<br>--------------------------------------------
<br><br> Key: JDO-606
<br> URL: <a href="https://issues.apache.org/jira/browse/JDO-606" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-606</a><br> Project: JDO
<br> Issue Type: Improvement
<br> Components: api2
<br> Affects Versions: JDO 2 maintenance release 2
<br> Reporter: Jörg von Frantzius
<br><br><br>On <a href="http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/jdo/jdo2-api/" target="_top" rel="nofollow">http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/jdo/jdo2-api/</a> there currently is no jars or POM information for 2.2 (-SNAPSHOT).
<br><br>I don't know how that's supposed to get there, but I hope somebody else does...
<br><br>Last but not least, this makes it hard for building and testing the RI itself using maven2, since the missing POM precludes the jdo2-api-2.2-SNAPSHOT.jar artifact from easy inclusion e.g. in .war files used for integration-tests with J2EE containers.
<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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19077734[jira] Resolved: (JDO-603) dist goal fails if top level dir does not end in "jdo"2008-08-20T13:46:44Z2008-08-20T13:46:44ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Michelle Caisse resolved JDO-603.
<br>---------------------------------
<br><br> Resolution: Fixed
<br><br>Completed: At revision: 687454
<br><br><div class='shrinkable-quote'><br>> dist goal fails if top level dir does not end in "jdo"
<br>> ------------------------------------------------------
<br>>
<br>> Key: JDO-603
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-603" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-603</a><br>> Project: JDO
<br>> Issue Type: Bug
<br>> Components: site and infrastructure
<br>> Affects Versions: JDO 2 maintenance release 1
<br>> Reporter: Michelle Caisse
<br>> Assignee: Michelle Caisse
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>>
<br>> The algorithm used to compute the dist directory requires that the top-level directory terminate in the string "jdo". The algorithm is codified in this line of trunk/project.properties:
<br>> jdo.releases.dir = ${basedir.substring(0, basedir.lastIndexOf('jdo'))}jdo/releases
<br>> This, for example, takes c:/jdoFooBar/branches/2.1.1 and converts it to c:/jdo/releases. It will fail completely for c:/code/branches/2.1.1.
<br>> A fix allowing an arbitrary string as the local tree top level directory is difficult because it needs to work for both <topdir>/trunk/ and <topdir>/branches/<version>. The solution is to document the requirements for the directory name in <topdir>/HowToReleaseJDO.html.
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19076758[jira] Commented: (JDO-558) Create tests for the serialization of PersistenceManagerFactory/PersistenceManager2008-08-20T12:46:44Z2008-08-20T12:46:44ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624110#action_12624110" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624110#action_12624110</a> ]
<br><br>Craig Russell commented on JDO-558:
<br>-----------------------------------
<br><br>Tests will serialize a PMF and then materialize it in the same VM (easy with the current JUnit setup), and make sure it's equivalent by getting a PM and trying to retrieve an instance by its id.
<br><br>A different test will serialize a PM and materialize it in the same VM. It should also be possible to retrieve an instance that was stored using the previous PMF.
<br><br>Another set of tests will create a new VM and try to materialize PMF and PM. This is more tricky with the current maven/JUnit setup since another VM needs to be created and communications established between the VMs.
<br><br><br><br><div class='shrinkable-quote'><br>> Create tests for the serialization of PersistenceManagerFactory/PersistenceManager
<br>> ----------------------------------------------------------------------------------
<br>>
<br>> Key: JDO-558
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-558" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-558</a><br>> Project: JDO
<br>> Issue Type: Task
<br>> Components: tck2, tck2-legacy
<br>> Affects Versions: JDO 2 maintenance release 1
<br>> Reporter: Matthew T. Adams
<br>> Assignee: Craig Russell
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>>
<br>> Serialization of PMFs/PMs needs to be tested as part of the TCK. Forthcoming spec updates on PM serialization will need assertions.
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19075220[jira] Resolved: (JDO-583) Add license headers to source files.2008-08-20T11:16:44Z2008-08-20T11:16:44ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Michelle Caisse resolved JDO-583.
<br>---------------------------------
<br><br> Resolution: Fixed
<br><br>Completed: At revision: 687404
<br><br>Works for both /* */ and // comments.
<br><br>License header added to signatures text file.
<br><div class='shrinkable-quote'><br>> Add license headers to source files.
<br>> ------------------------------------
<br>>
<br>> Key: JDO-583
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-583" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-583</a><br>> Project: JDO
<br>> Issue Type: Bug
<br>> Components: tck2, tck2-legacy
<br>> Affects Versions: JDO 2 maintenance release 1
<br>> Reporter: Craig Russell
<br>> Assignee: Michelle Caisse
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>> Attachments: SignatureVerifier.patch
<br>>
<br>>
<br>> RAT reveals files that need Apache license headers:
<br>> jdo2-tck-2.1/src/conf/jdo-2_1-signatures.txt
<br>> jdo2-tck-2.1/src/java/org/apache/jdo/tck/pc/company/ CompanyFactoryNewInstance.java
<br>> jdo2-tck-2.1/src/uml/org/apache/jdo/tck/pc/shoppingcart/ shoppingcart.argo.uml\
<br>> jdo2-tck-legacy-2.1/src/conf/jdo-2_1-signatures.txt
<br>> jdo2-tck-legacy-2.1/src/uml/org/apache/jdo/tck/pc/shoppingcart/ shoppingcart.argo.uml
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19040849[jira] Resolved: (JDO-554) JDO2.2 : Dynamic fetch groups2008-08-18T14:57:44Z2008-08-18T14:57:44ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Craig Russell resolved JDO-554.
<br>-------------------------------
<br><br> Resolution: Fixed
<br><div class='shrinkable-quote'><br>> JDO2.2 : Dynamic fetch groups
<br>> -----------------------------
<br>>
<br>> Key: JDO-554
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-554" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-554</a><br>> Project: JDO
<br>> Issue Type: New Feature
<br>> Components: api2, api2-legacy, specification
<br>> Reporter: Andy Jefferson
<br>> Assignee: Andy Jefferson
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
<br>>
<br>>
<br>> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
<br>> Below is a proposal that could possibly be included in a JDO2.2 (or in JDO2.1
<br>> if feedback is positive for that, and JPOX already implements it).
<br>> ========================================
<br>> Problem : fetch groups are static, defined in metadata (XML/annotations). Sometimes it would be more convenient to be able to define fetch groups dynamically, for example based on user interaction in a web system.
<br>> ========================================
<br>> Proposal :
<br>> We add a new interface defining a FetchGroup, where a FetchGroup has a symbolic name and is for a class defining the fields of that class that are in the fetch group.
<br>> public interface FetchGroup
<br>> {
<br>> String getName(); // Symbolic name (as also used in MetaData)
<br>> String getClassName(); // Class to which this group refers
<br>> FetchGroup add(String fieldName); // Add a field
<br>> FetchGroup remove(String fieldName); // Remove a field
<br>> boolean hasField(String fieldName);
<br>> String[] getFieldNames();
<br>> void setPostLoad(boolean postLoad);
<br>> boolean getPostLoad();
<br>> }
<br>> We allow users to register/deregister their FetchGroups with the PMF
<br>> PersistenceManagerFactory
<br>> {
<br>> ...
<br>> void addFetchGroup(FetchGroup grp);
<br>> void removeFetchGroup(String name, Class cls);
<br>> FetchGroup createFetchGroup(String name, Class cls);
<br>> FetchGroup getFetchGroup(String grpName, Class cls);
<br>> FetchGroup[] getFetchGroups();
<br>> void clearFetchGroups();
<br>> }
<br>> ========================================
<br>> Usage:
<br>> FetchGroup grp1 = pmf.createFetchGroup("myGroup1", MyClass.class);
<br>> grp1.add("field1").add("field2").add("field4");
<br>> pmf.addFetchGroup(grp1); // FetchGroup registered
<br>> pm.getFetchPlan().setGroup("myGroup1"); // FetchGroup used in this plan
<br>> // FetchPlan now has MyClass {field1, field2, field4}
<br>> We can then also allow dynamic changes like
<br>> pmf.getFetchGroup("myGroup1", MyClass.class).add("field7");
<br>> and this is directly reflected in the FetchPlan
<br>> Possible changes:-
<br>> 1. PMF has createFetchGroup and addFetchGroup and we could merge these so when creating a FetchGroup it is added
<br>> 2. Doesnt support "recursion-depth" specification when adding a field to a FetchGroup, so we could add a method "add(String fieldName, int depth)"
<br>> Comments by Erik Samson
<br>> JDO 2 needs alternate ways to define fetch plans. Some food for thoughts here:
<br>> - possibility to add the DFG of a class into a fetch group
<br>> - possibility to add all fields of a class into a fetch group
<br>> - possibility to add all primitive fields of a class into a fetch group
<br>> - possibility to add all reference fields of a class into a fetch group
<br>> - possibility to add all collections fields of a class into a fetch group
<br>> - possibility to remove all primitive fields of a class into a fetch group
<br>> - possibility to remove all reference fields of a class into a fetch group
<br>> - possibility to remove all collections fields of a class into a fetch group
<br>> - possibility to create a global fetch plan without fetch groups at all
<br>> pm.setFetchPlan( "Person(name,age, address( {dfg} , country( {all} , -flagIMG ) ), accounts( {simple} , +{references} ) )" ) ;
<br>> Person actually references the candidate class, so I suppose it could be optional.
<br>> This method will load name and age from a Person, then will load the configured DFG from the reference to Address, then will load all fields but flagIMG from the reference to Country into address, and finally will load simple fields and unary references to other objects from the collection of Accounts. We should also probably support depth in that mechanism.
<br>> Having this "SSFP" (Single String Fetch Plan) will allow to tune the system externally, from JMX or a configuration file for instance.
<br>> Comments by Matthew Adams
<br>> You might also consider overloaded methods on interface FetchGroup, just for completeness:
<br>> // (importing java.lang.reflect.Field)
<br>> FetchGroup add(Field field);
<br>> FetchGroup remove(Field field);
<br>> boolean hasField(Field field); // or has(Field) -- I'd consider better verb
<br>> Field[] getFields();
<br>> The add & remove methods should throw if the Field isn't contained in the class.
<br>> Comments by Christiaan:
<br>> May be also think about an option to restore to a fetchGroup to a state before you start changing it (possibly via supporting clone()) or reset to configuration defined in JDO file.
<br>> Comments by Craig Russell:
<br>> Also, I think that we should consider ways to manipulate FetchPlans as well, both in programmatic as well as declarative approaches. Specifically, I'd like to be able to specify in my configuration the FetchPlan to use in a specific application context, e.g. the first time a PersistenceManager is used to getObjectById or newQuery, the FetchPlan for that use case is looked up from configuration and set as the current FetchPlan.
<br>> Further, if the application wants a specific FetchPlan, they should be able to call a method setFetchPlan with either the name of a configured FetchPlan or a FetchPlan to use.
<br>> And then, assuming that the FetchPlan must change during some interval of application processing, and then reset to the previous settings,
<br>> public void pushFetchPlan(FetchPlan);
<br>> public void pushFetchPlan(String fetchPlanName)
<br>> public FetchPlan popFetchPlan()
<br>> would allow a temporary override of the FetchPlan without the application having to preserve the settings and update the FetchPlan to restore it.
<br>> In this light, it might make sense to be able to register FetchPlans by name with the PersistenceManagerFactory.
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19034310[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups2008-08-18T08:40:44Z2008-08-18T08:40:44ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623382#action_12623382" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623382#action_12623382</a> ]
<br><br>Craig Russell commented on JDO-554:
<br>-----------------------------------
<br><br>Very cool.
<br><br>The discussion about api2-legacy is timely. There are other features that would also need to go into the legacy code as well. Just need volunteers...
<br><div class='shrinkable-quote'><br>> JDO2.2 : Dynamic fetch groups
<br>> -----------------------------
<br>>
<br>> Key: JDO-554
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-554" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-554</a><br>> Project: JDO
<br>> Issue Type: New Feature
<br>> Components: api2, api2-legacy, specification
<br>> Reporter: Andy Jefferson
<br>> Assignee: Andy Jefferson
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
<br>>
<br>>
<br>> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
<br>> Below is a proposal that could possibly be included in a JDO2.2 (or in JDO2.1
<br>> if feedback is positive for that, and JPOX already implements it).
<br>> ========================================
<br>> Problem : fetch groups are static, defined in metadata (XML/annotations). Sometimes it would be more convenient to be able to define fetch groups dynamically, for example based on user interaction in a web system.
<br>> ========================================
<br>> Proposal :
<br>> We add a new interface defining a FetchGroup, where a FetchGroup has a symbolic name and is for a class defining the fields of that class that are in the fetch group.
<br>> public interface FetchGroup
<br>> {
<br>> String getName(); // Symbolic name (as also used in MetaData)
<br>> String getClassName(); // Class to which this group refers
<br>> FetchGroup add(String fieldName); // Add a field
<br>> FetchGroup remove(String fieldName); // Remove a field
<br>> boolean hasField(String fieldName);
<br>> String[] getFieldNames();
<br>> void setPostLoad(boolean postLoad);
<br>> boolean getPostLoad();
<br>> }
<br>> We allow users to register/deregister their FetchGroups with the PMF
<br>> PersistenceManagerFactory
<br>> {
<br>> ...
<br>> void addFetchGroup(FetchGroup grp);
<br>> void removeFetchGroup(String name, Class cls);
<br>> FetchGroup createFetchGroup(String name, Class cls);
<br>> FetchGroup getFetchGroup(String grpName, Class cls);
<br>> FetchGroup[] getFetchGroups();
<br>> void clearFetchGroups();
<br>> }
<br>> ========================================
<br>> Usage:
<br>> FetchGroup grp1 = pmf.createFetchGroup("myGroup1", MyClass.class);
<br>> grp1.add("field1").add("field2").add("field4");
<br>> pmf.addFetchGroup(grp1); // FetchGroup registered
<br>> pm.getFetchPlan().setGroup("myGroup1"); // FetchGroup used in this plan
<br>> // FetchPlan now has MyClass {field1, field2, field4}
<br>> We can then also allow dynamic changes like
<br>> pmf.getFetchGroup("myGroup1", MyClass.class).add("field7");
<br>> and this is directly reflected in the FetchPlan
<br>> Possible changes:-
<br>> 1. PMF has createFetchGroup and addFetchGroup and we could merge these so when creating a FetchGroup it is added
<br>> 2. Doesnt support "recursion-depth" specification when adding a field to a FetchGroup, so we could add a method "add(String fieldName, int depth)"
<br>> Comments by Erik Samson
<br>> JDO 2 needs alternate ways to define fetch plans. Some food for thoughts here:
<br>> - possibility to add the DFG of a class into a fetch group
<br>> - possibility to add all fields of a class into a fetch group
<br>> - possibility to add all primitive fields of a class into a fetch group
<br>> - possibility to add all reference fields of a class into a fetch group
<br>> - possibility to add all collections fields of a class into a fetch group
<br>> - possibility to remove all primitive fields of a class into a fetch group
<br>> - possibility to remove all reference fields of a class into a fetch group
<br>> - possibility to remove all collections fields of a class into a fetch group
<br>> - possibility to create a global fetch plan without fetch groups at all
<br>> pm.setFetchPlan( "Person(name,age, address( {dfg} , country( {all} , -flagIMG ) ), accounts( {simple} , +{references} ) )" ) ;
<br>> Person actually references the candidate class, so I suppose it could be optional.
<br>> This method will load name and age from a Person, then will load the configured DFG from the reference to Address, then will load all fields but flagIMG from the reference to Country into address, and finally will load simple fields and unary references to other objects from the collection of Accounts. We should also probably support depth in that mechanism.
<br>> Having this "SSFP" (Single String Fetch Plan) will allow to tune the system externally, from JMX or a configuration file for instance.
<br>> Comments by Matthew Adams
<br>> You might also consider overloaded methods on interface FetchGroup, just for completeness:
<br>> // (importing java.lang.reflect.Field)
<br>> FetchGroup add(Field field);
<br>> FetchGroup remove(Field field);
<br>> boolean hasField(Field field); // or has(Field) -- I'd consider better verb
<br>> Field[] getFields();
<br>> The add & remove methods should throw if the Field isn't contained in the class.
<br>> Comments by Christiaan:
<br>> May be also think about an option to restore to a fetchGroup to a state before you start changing it (possibly via supporting clone()) or reset to configuration defined in JDO file.
<br>> Comments by Craig Russell:
<br>> Also, I think that we should consider ways to manipulate FetchPlans as well, both in programmatic as well as declarative approaches. Specifically, I'd like to be able to specify in my configuration the FetchPlan to use in a specific application context, e.g. the first time a PersistenceManager is used to getObjectById or newQuery, the FetchPlan for that use case is looked up from configuration and set as the current FetchPlan.
<br>> Further, if the application wants a specific FetchPlan, they should be able to call a method setFetchPlan with either the name of a configured FetchPlan or a FetchPlan to use.
<br>> And then, assuming that the FetchPlan must change during some interval of application processing, and then reset to the previous settings,
<br>> public void pushFetchPlan(FetchPlan);
<br>> public void pushFetchPlan(String fetchPlanName)
<br>> public FetchPlan popFetchPlan()
<br>> would allow a temporary override of the FetchPlan without the application having to preserve the settings and update the FetchPlan to restore it.
<br>> In this light, it might make sense to be able to register FetchPlans by name with the PersistenceManagerFactory.
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19034145Re: JDK level support in JDO2008-08-18T08:32:06Z2008-08-18T08:32:06ZCraig L RussellHi Andy,
<br><br>On Aug 18, 2008, at 7:41 AM, Andy Jefferson wrote:
<br><div class='shrinkable-quote'><div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> all previous JDO releases have always supported JDKs 1.3 and above.
<br>> JDO2.1 started providing the "api2-legacy" for JDK1.3/4, and "api2"
<br>> for
<br>> JDK1.5+ specifics.
<br>>
<br>> Just a note about DataNucleus AccessPlatform support levels.
<br>> 1. AccessPlatform 1.0 will be the last release that will support
<br>> JDK1.3/1.4.
<br>> 2. AccessPlatform 1.1 will support JDK1.5+ only.
<br>>
<br>> AccessPlatform 1.0 will be branched at its 1.0 final release (start
<br>> of Sept)
<br>> and there could be minor releases on that branch after this point,
<br>> but we
<br>> just don't have the resources to support 2 branches for any period.
<br>>
<br>>
<br>> What are the Apache JDO timescales for dropping support for
<br>> JDK1.3/1.4 ?
<br>> Perhaps make JDO2.2 the final release supporting JDK1.3/1.4?
</div></div>I'd be happy with either JDO 2.1 or JDO 2.2 being the last release to
<br>support the legacy JVMs. Subject to the community, of course (and
<br>subject to people to do the work).
<br><br>There's real work in migrating the 2.2 work done so far to the 2.1
<br>platform, and I'd be happy to help a volunteer to do it. Not so keen
<br>on doing all the work myself.
<br><br>Craig
<br>>
<br>>
<br>>
<br>>
<br>> --
<br>> Andy (DataNucleus - <a href="http://www.datanucleus.org" target="_top" rel="nofollow">http://www.datanucleus.org</a>)
<br><br>Craig L Russell
<br>Architect, Sun Java Enterprise System <a href="http://java.sun.com/products/jdo" target="_top" rel="nofollow">http://java.sun.com/products/jdo</a><br>408 276-5638 mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19034145&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://www.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (3K) <a href="http://www.nabble.com/attachment/19034145/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19033174JDK level support in JDO2008-08-18T07:41:00Z2008-08-18T07:41:00ZAndy Jefferson-4Hi,
<br><br>all previous JDO releases have always supported JDKs 1.3 and above.
<br>JDO2.1 started providing the "api2-legacy" for JDK1.3/4, and "api2" for
<br>JDK1.5+ specifics.
<br><br>Just a note about DataNucleus AccessPlatform support levels.
<br>1. AccessPlatform 1.0 will be the last release that will support JDK1.3/1.4.
<br>2. AccessPlatform 1.1 will support JDK1.5+ only.
<br><br>AccessPlatform 1.0 will be branched at its 1.0 final release (start of Sept)
<br>and there could be minor releases on that branch after this point, but we
<br>just don't have the resources to support 2 branches for any period.
<br><br><br>What are the Apache JDO timescales for dropping support for JDK1.3/1.4 ?
<br>Perhaps make JDO2.2 the final release supporting JDK1.3/1.4?
<br><br><br><br>--
<br>Andy (DataNucleus - <a href="http://www.datanucleus.org" target="_top" rel="nofollow">http://www.datanucleus.org</a>)
<br><p>From forum: <a href="http://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19033044[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups2008-08-18T07:33:44Z2008-08-18T07:33:44ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623359#action_12623359" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623359#action_12623359</a> ]
<br><br>Andy Jefferson commented on JDO-554:
<br>------------------------------------
<br><br>DataNucleus SVN (and nightly build) passes all TCK tests.
<br>fetchgroup.conf is now part of configurations.list in Apache JDO SVN
<br><br>PS. Does FetchGroup also need to go into api2-legacy? It isn't there currently, and I don't see anything JDK1.5 specific in it.
<br><div class='shrinkable-quote'><br>> JDO2.2 : Dynamic fetch groups
<br>> -----------------------------
<br>>
<br>> Key: JDO-554
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-554" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-554</a><br>> Project: JDO
<br>> Issue Type: New Feature
<br>> Components: api2, api2-legacy, specification
<br>> Reporter: Andy Jefferson
<br>> Assignee: Andy Jefferson
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
<br>>
<br>>
<br>> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
<br>> Below is a proposal that could possibly be included in a JDO2.2 (or in JDO2.1
<br>> if feedback is positive for that, and JPOX already implements it).
<br>> ========================================
<br>> Problem : fetch groups are static, defined in metadata (XML/annotations). Sometimes it would be more convenient to be able to define fetch groups dynamically, for example based on user interaction in a web system.
<br>> ========================================
<br>> Proposal :
<br>> We add a new interface defining a FetchGroup, where a FetchGroup has a symbolic name and is for a class defining the fields of that class that are in the fetch group.
<br>> public interface FetchGroup
<br>> {
<br>> String getName(); // Symbolic name (as also used in MetaData)
<br>> String getClassName(); // Class to which this group refers
<br>> FetchGroup add(String fieldName); // Add a field
<br>> FetchGroup remove(String fieldName); // Remove a field
<br>> boolean hasField(String fieldName);
<br>> String[] getFieldNames();
<br>> void setPostLoad(boolean postLoad);
<br>> boolean getPostLoad();
<br>> }
<br>> We allow users to register/deregister their FetchGroups with the PMF
<br>> PersistenceManagerFactory
<br>> {
<br>> ...
<br>> void addFetchGroup(FetchGroup grp);
<br>> void removeFetchGroup(String name, Class cls);
<br>> FetchGroup createFetchGroup(String name, Class cls);
<br>> FetchGroup getFetchGroup(String grpName, Class cls);
<br>> FetchGroup[] getFetchGroups();
<br>> void clearFetchGroups();
<br>> }
<br>> ========================================
<br>> Usage:
<br>> FetchGroup grp1 = pmf.createFetchGroup("myGroup1", MyClass.class);
<br>> grp1.add("field1").add("field2").add("field4");
<br>> pmf.addFetchGroup(grp1); // FetchGroup registered
<br>> pm.getFetchPlan().setGroup("myGroup1"); // FetchGroup used in this plan
<br>> // FetchPlan now has MyClass {field1, field2, field4}
<br>> We can then also allow dynamic changes like
<br>> pmf.getFetchGroup("myGroup1", MyClass.class).add("field7");
<br>> and this is directly reflected in the FetchPlan
<br>> Possible changes:-
<br>> 1. PMF has createFetchGroup and addFetchGroup and we could merge these so when creating a FetchGroup it is added
<br>> 2. Doesnt support "recursion-depth" specification when adding a field to a FetchGroup, so we could add a method "add(String fieldName, int depth)"
<br>> Comments by Erik Samson
<br>> JDO 2 needs alternate ways to define fetch plans. Some food for thoughts here:
<br>> - possibility to add the DFG of a class into a fetch group
<br>> - possibility to add all fields of a class into a fetch group
<br>> - possibility to add all primitive fields of a class into a fetch group
<br>> - possibility to add all reference fields of a class into a fetch group
<br>> - possibility to add all collections fields of a class into a fetch group
<br>> - possibility to remove all primitive fields of a class into a fetch group
<br>> - possibility to remove all reference fields of a class into a fetch group
<br>> - possibility to remove all collections fields of a class into a fetch group
<br>> - possibility to create a global fetch plan without fetch groups at all
<br>> pm.setFetchPlan( "Person(name,age, address( {dfg} , country( {all} , -flagIMG ) ), accounts( {simple} , +{references} ) )" ) ;
<br>> Person actually references the candidate class, so I suppose it could be optional.
<br>> This method will load name and age from a Person, then will load the configured DFG from the reference to Address, then will load all fields but flagIMG from the reference to Country into address, and finally will load simple fields and unary references to other objects from the collection of Accounts. We should also probably support depth in that mechanism.
<br>> Having this "SSFP" (Single String Fetch Plan) will allow to tune the system externally, from JMX or a configuration file for instance.
<br>> Comments by Matthew Adams
<br>> You might also consider overloaded methods on interface FetchGroup, just for completeness:
<br>> // (importing java.lang.reflect.Field)
<br>> FetchGroup add(Field field);
<br>> FetchGroup remove(Field field);
<br>> boolean hasField(Field field); // or has(Field) -- I'd consider better verb
<br>> Field[] getFields();
<br>> The add & remove methods should throw if the Field isn't contained in the class.
<br>> Comments by Christiaan:
<br>> May be also think about an option to restore to a fetchGroup to a state before you start changing it (possibly via supporting clone()) or reset to configuration defined in JDO file.
<br>> Comments by Craig Russell:
<br>> Also, I think that we should consider ways to manipulate FetchPlans as well, both in programmatic as well as declarative approaches. Specifically, I'd like to be able to specify in my configuration the FetchPlan to use in a specific application context, e.g. the first time a PersistenceManager is used to getObjectById or newQuery, the FetchPlan for that use case is looked up from configuration and set as the current FetchPlan.
<br>> Further, if the application wants a specific FetchPlan, they should be able to call a method setFetchPlan with either the name of a configured FetchPlan or a FetchPlan to use.
<br>> And then, assuming that the FetchPlan must change during some interval of application processing, and then reset to the previous settings,
<br>> public void pushFetchPlan(FetchPlan);
<br>> public void pushFetchPlan(String fetchPlanName)
<br>> public FetchPlan popFetchPlan()
<br>> would allow a temporary override of the FetchPlan without the application having to preserve the settings and update the FetchPlan to restore it.
<br>> In this light, it might make sense to be able to register FetchPlans by name with the PersistenceManagerFactory.
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19008041[jira] Commented: (JDO-603) dist goal fails if top level dir does not end in "jdo"2008-08-15T19:17:44Z2008-08-15T19:17:44ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623075#action_12623075" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623075#action_12623075</a> ]
<br><br>Craig Russell commented on JDO-603:
<br>-----------------------------------
<br><br>Good idea. The dist goal should not continue if the directory is wrongly named.
<br><br><br><div class='shrinkable-quote'><br>> dist goal fails if top level dir does not end in "jdo"
<br>> ------------------------------------------------------
<br>>
<br>> Key: JDO-603
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-603" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-603</a><br>> Project: JDO
<br>> Issue Type: Bug
<br>> Components: site and infrastructure
<br>> Affects Versions: JDO 2 maintenance release 1
<br>> Reporter: Michelle Caisse
<br>> Assignee: Michelle Caisse
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>>
<br>> The algorithm used to compute the dist directory requires that the top-level directory terminate in the string "jdo". The algorithm is codified in this line of trunk/project.properties:
<br>> jdo.releases.dir = ${basedir.substring(0, basedir.lastIndexOf('jdo'))}jdo/releases
<br>> This, for example, takes c:/jdoFooBar/branches/2.1.1 and converts it to c:/jdo/releases. It will fail completely for c:/code/branches/2.1.1.
<br>> A fix allowing an arbitrary string as the local tree top level directory is difficult because it needs to work for both <topdir>/trunk/ and <topdir>/branches/<version>. The solution is to document the requirements for the directory name in <topdir>/HowToReleaseJDO.html.
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19007908[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups2008-08-15T18:49:44Z2008-08-15T18:49:44ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623073#action_12623073" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623073#action_12623073</a> ]
<br><br>Craig Russell commented on JDO-554:
<br>-----------------------------------
<br><br>> also in the test you helpfully added the relevant bit of Employee/Person classes with the fields but phoneNumbers/address haven't been transferred to the list(s) of expected members
<br><br>Right.
<br><br>> 1. testCategoriesInterface assumes that IEmployee is a persistent interface whereas in fact it isn't. Should this be PIEmployee?
<br><br>This test was renamed and turned into a failing case, and PIEmployee is now used for a positive test.
<br><br>> 2. testAddMember has its final check for the number of members yet seems to be 1 behind with the size. If i is 0 then there should be (i+1) members. Maybe testRemoveMember has something similar? not got that far yet.
<br><br>I've looked at this, and testAddMember has been fixed to expect one more than the index. But testRemoveMember should be correct as is.
<br><br>I've checked in a new version with more diagnostics.
<br><br>svn commit -m "JDO-554 Added diagnostics, fixed errors"
<br>Sending tck2/src/java/org/apache/jdo/tck/api/fetchgroup/FetchGroupTest.java
<br>Transmitting file data .
<br>Committed revision 686437.
<br><br><br><div class='shrinkable-quote'><br>> JDO2.2 : Dynamic fetch groups
<br>> -----------------------------
<br>>
<br>> Key: JDO-554
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-554" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-554</a><br>> Project: JDO
<br>> Issue Type: New Feature
<br>> Components: api2, api2-legacy, specification
<br>> Reporter: Andy Jefferson
<br>> Assignee: Andy Jefferson
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
<br>>
<br>>
<br>> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
<br>> Below is a proposal that could possibly be included in a JDO2.2 (or in JDO2.1
<br>> if feedback is positive for that, and JPOX already implements it).
<br>> ========================================
<br>> Problem : fetch groups are static, defined in metadata (XML/annotations). Sometimes it would be more convenient to be able to define fetch groups dynamically, for example based on user interaction in a web system.
<br>> ========================================
<br>> Proposal :
<br>> We add a new interface defining a FetchGroup, where a FetchGroup has a symbolic name and is for a class defining the fields of that class that are in the fetch group.
<br>> public interface FetchGroup
<br>> {
<br>> String getName(); // Symbolic name (as also used in MetaData)
<br>> String getClassName(); // Class to which this group refers
<br>> FetchGroup add(String fieldName); // Add a field
<br>> FetchGroup remove(String fieldName); // Remove a field
<br>> boolean hasField(String fieldName);
<br>> String[] getFieldNames();
<br>> void setPostLoad(boolean postLoad);
<br>> boolean getPostLoad();
<br>> }
<br>> We allow users to register/deregister their FetchGroups with the PMF
<br>> PersistenceManagerFactory
<br>> {
<br>> ...
<br>> void addFetchGroup(FetchGroup grp);
<br>> void removeFetchGroup(String name, Class cls);
<br>> FetchGroup createFetchGroup(String name, Class cls);
<br>> FetchGroup getFetchGroup(String grpName, Class cls);
<br>> FetchGroup[] getFetchGroups();
<br>> void clearFetchGroups();
<br>> }
<br>> ========================================
<br>> Usage:
<br>> FetchGroup grp1 = pmf.createFetchGroup("myGroup1", MyClass.class);
<br>> grp1.add("field1").add("field2").add("field4");
<br>> pmf.addFetchGroup(grp1); // FetchGroup registered
<br>> pm.getFetchPlan().setGroup("myGroup1"); // FetchGroup used in this plan
<br>> // FetchPlan now has MyClass {field1, field2, field4}
<br>> We can then also allow dynamic changes like
<br>> pmf.getFetchGroup("myGroup1", MyClass.class).add("field7");
<br>> and this is directly reflected in the FetchPlan
<br>> Possible changes:-
<br>> 1. PMF has createFetchGroup and addFetchGroup and we could merge these so when creating a FetchGroup it is added
<br>> 2. Doesnt support "recursion-depth" specification when adding a field to a FetchGroup, so we could add a method "add(String fieldName, int depth)"
<br>> Comments by Erik Samson
<br>> JDO 2 needs alternate ways to define fetch plans. Some food for thoughts here:
<br>> - possibility to add the DFG of a class into a fetch group
<br>> - possibility to add all fields of a class into a fetch group
<br>> - possibility to add all primitive fields of a class into a fetch group
<br>> - possibility to add all reference fields of a class into a fetch group
<br>> - possibility to add all collections fields of a class into a fetch group
<br>> - possibility to remove all primitive fields of a class into a fetch group
<br>> - possibility to remove all reference fields of a class into a fetch group
<br>> - possibility to remove all collections fields of a class into a fetch group
<br>> - possibility to create a global fetch plan without fetch groups at all
<br>> pm.setFetchPlan( "Person(name,age, address( {dfg} , country( {all} , -flagIMG ) ), accounts( {simple} , +{references} ) )" ) ;
<br>> Person actually references the candidate class, so I suppose it could be optional.
<br>> This method will load name and age from a Person, then will load the configured DFG from the reference to Address, then will load all fields but flagIMG from the reference to Country into address, and finally will load simple fields and unary references to other objects from the collection of Accounts. We should also probably support depth in that mechanism.
<br>> Having this "SSFP" (Single String Fetch Plan) will allow to tune the system externally, from JMX or a configuration file for instance.
<br>> Comments by Matthew Adams
<br>> You might also consider overloaded methods on interface FetchGroup, just for completeness:
<br>> // (importing java.lang.reflect.Field)
<br>> FetchGroup add(Field field);
<br>> FetchGroup remove(Field field);
<br>> boolean hasField(Field field); // or has(Field) -- I'd consider better verb
<br>> Field[] getFields();
<br>> The add & remove methods should throw if the Field isn't contained in the class.
<br>> Comments by Christiaan:
<br>> May be also think about an option to restore to a fetchGroup to a state before you start changing it (possibly via supporting clone()) or reset to configuration defined in JDO file.
<br>> Comments by Craig Russell:
<br>> Also, I think that we should consider ways to manipulate FetchPlans as well, both in programmatic as well as declarative approaches. Specifically, I'd like to be able to specify in my configuration the FetchPlan to use in a specific application context, e.g. the first time a PersistenceManager is used to getObjectById or newQuery, the FetchPlan for that use case is looked up from configuration and set as the current FetchPlan.
<br>> Further, if the application wants a specific FetchPlan, they should be able to call a method setFetchPlan with either the name of a configured FetchPlan or a FetchPlan to use.
<br>> And then, assuming that the FetchPlan must change during some interval of application processing, and then reset to the previous settings,
<br>> public void pushFetchPlan(FetchPlan);
<br>> public void pushFetchPlan(String fetchPlanName)
<br>> public FetchPlan popFetchPlan()
<br>> would allow a temporary override of the FetchPlan without the application having to preserve the settings and update the FetchPlan to restore it.
<br>> In this light, it might make sense to be able to register FetchPlans by name with the PersistenceManagerFactory.
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19007059[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups2008-08-15T16:37:44Z2008-08-15T16:37:44ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623058#action_12623058" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623058#action_12623058</a> ]
<br><br>Craig Russell commented on JDO-554:
<br>-----------------------------------
<br><br>I think Date should be a basic type, since the intent is things that are represented as a simple mapping of a single column. Here's a proposed update to the javadoc:
<br> /**
<br> * For use with {@link #addCategory} and {@link #removeCategory} calls.
<br> * This category includes members of all primitive and immutable
<br> * object class types as defined in section 6.4 of the specification,
<br> * including String, Locale, Currency, BigDecimal, and BigInteger;
<br> * as well as Date and its jdbc subtypes and Enum types.
<br> * @since 2.2
<br> */
<br> public static final String BASIC = "basic";
<br><br><br><br><div class='shrinkable-quote'><br>> JDO2.2 : Dynamic fetch groups
<br>> -----------------------------
<br>>
<br>> Key: JDO-554
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-554" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-554</a><br>> Project: JDO
<br>> Issue Type: New Feature
<br>> Components: api2, api2-legacy, specification
<br>> Reporter: Andy Jefferson
<br>> Assignee: Andy Jefferson
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
<br>>
<br>>
<br>> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
<br>> Below is a proposal that could possibly be included in a JDO2.2 (or in JDO2.1
<br>> if feedback is positive for that, and JPOX already implements it).
<br>> ========================================
<br>> Problem : fetch groups are static, defined in metadata (XML/annotations). Sometimes it would be more convenient to be able to define fetch groups dynamically, for example based on user interaction in a web system.
<br>> ========================================
<br>> Proposal :
<br>> We add a new interface defining a FetchGroup, where a FetchGroup has a symbolic name and is for a class defining the fields of that class that are in the fetch group.
<br>> public interface FetchGroup
<br>> {
<br>> String getName(); // Symbolic name (as also used in MetaData)
<br>> String getClassName(); // Class to which this group refers
<br>> FetchGroup add(String fieldName); // Add a field
<br>> FetchGroup remove(String fieldName); // Remove a field
<br>> boolean hasField(String fieldName);
<br>> String[] getFieldNames();
<br>> void setPostLoad(boolean postLoad);
<br>> boolean getPostLoad();
<br>> }
<br>> We allow users to register/deregister their FetchGroups with the PMF
<br>> PersistenceManagerFactory
<br>> {
<br>> ...
<br>> void addFetchGroup(FetchGroup grp);
<br>> void removeFetchGroup(String name, Class cls);
<br>> FetchGroup createFetchGroup(String name, Class cls);
<br>> FetchGroup getFetchGroup(String grpName, Class cls);
<br>> FetchGroup[] getFetchGroups();
<br>> void clearFetchGroups();
<br>> }
<br>> ========================================
<br>> Usage:
<br>> FetchGroup grp1 = pmf.createFetchGroup("myGroup1", MyClass.class);
<br>> grp1.add("field1").add("field2").add("field4");
<br>> pmf.addFetchGroup(grp1); // FetchGroup registered
<br>> pm.getFetchPlan().setGroup("myGroup1"); // FetchGroup used in this plan
<br>> // FetchPlan now has MyClass {field1, field2, field4}
<br>> We can then also allow dynamic changes like
<br>> pmf.getFetchGroup("myGroup1", MyClass.class).add("field7");
<br>> and this is directly reflected in the FetchPlan
<br>> Possible changes:-
<br>> 1. PMF has createFetchGroup and addFetchGroup and we could merge these so when creating a FetchGroup it is added
<br>> 2. Doesnt support "recursion-depth" specification when adding a field to a FetchGroup, so we could add a method "add(String fieldName, int depth)"
<br>> Comments by Erik Samson
<br>> JDO 2 needs alternate ways to define fetch plans. Some food for thoughts here:
<br>> - possibility to add the DFG of a class into a fetch group
<br>> - possibility to add all fields of a class into a fetch group
<br>> - possibility to add all primitive fields of a class into a fetch group
<br>> - possibility to add all reference fields of a class into a fetch group
<br>> - possibility to add all collections fields of a class into a fetch group
<br>> - possibility to remove all primitive fields of a class into a fetch group
<br>> - possibility to remove all reference fields of a class into a fetch group
<br>> - possibility to remove all collections fields of a class into a fetch group
<br>> - possibility to create a global fetch plan without fetch groups at all
<br>> pm.setFetchPlan( "Person(name,age, address( {dfg} , country( {all} , -flagIMG ) ), accounts( {simple} , +{references} ) )" ) ;
<br>> Person actually references the candidate class, so I suppose it could be optional.
<br>> This method will load name and age from a Person, then will load the configured DFG from the reference to Address, then will load all fields but flagIMG from the reference to Country into address, and finally will load simple fields and unary references to other objects from the collection of Accounts. We should also probably support depth in that mechanism.
<br>> Having this "SSFP" (Single String Fetch Plan) will allow to tune the system externally, from JMX or a configuration file for instance.
<br>> Comments by Matthew Adams
<br>> You might also consider overloaded methods on interface FetchGroup, just for completeness:
<br>> // (importing java.lang.reflect.Field)
<br>> FetchGroup add(Field field);
<br>> FetchGroup remove(Field field);
<br>> boolean hasField(Field field); // or has(Field) -- I'd consider better verb
<br>> Field[] getFields();
<br>> The add & remove methods should throw if the Field isn't contained in the class.
<br>> Comments by Christiaan:
<br>> May be also think about an option to restore to a fetchGroup to a state before you start changing it (possibly via supporting clone()) or reset to configuration defined in JDO file.
<br>> Comments by Craig Russell:
<br>> Also, I think that we should consider ways to manipulate FetchPlans as well, both in programmatic as well as declarative approaches. Specifically, I'd like to be able to specify in my configuration the FetchPlan to use in a specific application context, e.g. the first time a PersistenceManager is used to getObjectById or newQuery, the FetchPlan for that use case is looked up from configuration and set as the current FetchPlan.
<br>> Further, if the application wants a specific FetchPlan, they should be able to call a method setFetchPlan with either the name of a configured FetchPlan or a FetchPlan to use.
<br>> And then, assuming that the FetchPlan must change during some interval of application processing, and then reset to the previous settings,
<br>> public void pushFetchPlan(FetchPlan);
<br>> public void pushFetchPlan(String fetchPlanName)
<br>> public FetchPlan popFetchPlan()
<br>> would allow a temporary override of the FetchPlan without the application having to preserve the settings and update the FetchPlan to restore it.
<br>> In this light, it might make sense to be able to register FetchPlans by name with the PersistenceManagerFactory.
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19006891[jira] Commented: (JDO-583) Add license headers to source files.2008-08-15T16:17:44Z2008-08-15T16:17:44ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623054#action_12623054" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623054#action_12623054</a> ]
<br><br>Craig Russell commented on JDO-583:
<br>-----------------------------------
<br><br>Looks good. Were you planning on adding the // style comments?
<br><br><br><br><div class='shrinkable-quote'><br>> Add license headers to source files.
<br>> ------------------------------------
<br>>
<br>> Key: JDO-583
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-583" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-583</a><br>> Project: JDO
<br>> Issue Type: Bug
<br>> Components: tck2, tck2-legacy
<br>> Affects Versions: JDO 2 maintenance release 1
<br>> Reporter: Craig Russell
<br>> Assignee: Michelle Caisse
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>> Attachments: SignatureVerifier.patch
<br>>
<br>>
<br>> RAT reveals files that need Apache license headers:
<br>> jdo2-tck-2.1/src/conf/jdo-2_1-signatures.txt
<br>> jdo2-tck-2.1/src/java/org/apache/jdo/tck/pc/company/ CompanyFactoryNewInstance.java
<br>> jdo2-tck-2.1/src/uml/org/apache/jdo/tck/pc/shoppingcart/ shoppingcart.argo.uml\
<br>> jdo2-tck-legacy-2.1/src/conf/jdo-2_1-signatures.txt
<br>> jdo2-tck-legacy-2.1/src/uml/org/apache/jdo/tck/pc/shoppingcart/ shoppingcart.argo.uml
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19006706[jira] Resolved: (JDO-597) PMF : Add "readOnly" setting for better handling of read-only datastores2008-08-15T15:55:44Z2008-08-15T15:55:44ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Craig Russell resolved JDO-597.
<br>-------------------------------
<br><br> Resolution: Fixed
<br><br>All tck tests now pass.
<br><div class='shrinkable-quote'><br>> PMF : Add "readOnly" setting for better handling of read-only datastores
<br>> ------------------------------------------------------------------------
<br>>
<br>> Key: JDO-597
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-597" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-597</a><br>> Project: JDO
<br>> Issue Type: New Feature
<br>> Components: api2, api2-legacy, specification
<br>> Reporter: Andy Jefferson
<br>> Assignee: Andy Jefferson
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>> Attachments: JDOReadOnlyException.patch
<br>>
<br>>
<br>> A user has a datastore that is outside their control and they either don't have permission to write to it, or maybe they have permissions but don't want to write to it. They want a better way of handling this, preventing updates to the datastore.
<br>> Propose :-
<br>> PMF property (with setter/getter)
<br>> javax.jdo.option.ReadOnly - values true | false
<br>> JDOReadOnlyException extends JDOUserException
<br>> Behaviour :-
<br>> When readOnly is set to true :-
<br>> Any operation resulting in a creation/modification of an object to be sent to the datastore should throw a JDOReadOnlyException. This may be at commit(), flush(), or alternatively at makePersistent() when using datastore txns, or query.deletePersistentAll(). That is, no change should be made to the datastore contents at all.
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19006709[jira] Commented: (JDO-597) PMF : Add "readOnly" setting for better handling of read-only datastores2008-08-15T15:55:44Z2008-08-15T15:55:44ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623051#action_12623051" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623051#action_12623051</a> ]
<br><br>Craig Russell commented on JDO-597:
<br>-----------------------------------
<br><br>Loading the oid class did the trick.
<br><br>svn commit -m "JDO-597 Make sure oid class is loaded"
<br>Sending tck2/src/java/org/apache/jdo/tck/api/persistencemanagerfactory/FlushThrowsIfReadOnly.java
<br>Transmitting file data .
<br>Committed revision 686413.
<br><br><br><div class='shrinkable-quote'><br>> PMF : Add "readOnly" setting for better handling of read-only datastores
<br>> ------------------------------------------------------------------------
<br>>
<br>> Key: JDO-597
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-597" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-597</a><br>> Project: JDO
<br>> Issue Type: New Feature
<br>> Components: api2, api2-legacy, specification
<br>> Reporter: Andy Jefferson
<br>> Assignee: Andy Jefferson
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>> Attachments: JDOReadOnlyException.patch
<br>>
<br>>
<br>> A user has a datastore that is outside their control and they either don't have permission to write to it, or maybe they have permissions but don't want to write to it. They want a better way of handling this, preventing updates to the datastore.
<br>> Propose :-
<br>> PMF property (with setter/getter)
<br>> javax.jdo.option.ReadOnly - values true | false
<br>> JDOReadOnlyException extends JDOUserException
<br>> Behaviour :-
<br>> When readOnly is set to true :-
<br>> Any operation resulting in a creation/modification of an object to be sent to the datastore should throw a JDOReadOnlyException. This may be at commit(), flush(), or alternatively at makePersistent() when using datastore txns, or query.deletePersistentAll(). That is, no change should be made to the datastore contents at all.
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19004030[jira] Commented: (JDO-597) PMF : Add "readOnly" setting for better handling of read-only datastores2008-08-15T12:07:44Z2008-08-15T12:07:44ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622985#action_12622985" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622985#action_12622985</a> ]
<br><br>Craig Russell commented on JDO-597:
<br>-----------------------------------
<br><br>Added constants to signatures file.
<br><br>svn commit -m "JDO-597 Update signatures for readonly Constants" src/conf/jdo-2_2-signatures.txt
<br>Sending src/conf/jdo-2_2-signatures.txt
<br>Transmitting file data .
<br>Committed revision 686326.
<br><br><br><div class='shrinkable-quote'><br>> PMF : Add "readOnly" setting for better handling of read-only datastores
<br>> ------------------------------------------------------------------------
<br>>
<br>> Key: JDO-597
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-597" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-597</a><br>> Project: JDO
<br>> Issue Type: New Feature
<br>> Components: api2, api2-legacy, specification
<br>> Reporter: Andy Jefferson
<br>> Assignee: Andy Jefferson
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>> Attachments: JDOReadOnlyException.patch
<br>>
<br>>
<br>> A user has a datastore that is outside their control and they either don't have permission to write to it, or maybe they have permissions but don't want to write to it. They want a better way of handling this, preventing updates to the datastore.
<br>> Propose :-
<br>> PMF property (with setter/getter)
<br>> javax.jdo.option.ReadOnly - values true | false
<br>> JDOReadOnlyException extends JDOUserException
<br>> Behaviour :-
<br>> When readOnly is set to true :-
<br>> Any operation resulting in a creation/modification of an object to be sent to the datastore should throw a JDOReadOnlyException. This may be at commit(), flush(), or alternatively at makePersistent() when using datastore txns, or query.deletePersistentAll(). That is, no change should be made to the datastore contents at all.
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19004015[jira] Updated: (JDO-583) Add license headers to source files.2008-08-15T12:05:44Z2008-08-15T12:05:44ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel</a> ]
<br><br>Michelle Caisse updated JDO-583:
<br>--------------------------------
<br><br> Attachment: SignatureVerifier.patch
<br><br>The attached patch seems to work, but could use a bit of clean-up, I think.
<br><div class='shrinkable-quote'><br>> Add license headers to source files.
<br>> ------------------------------------
<br>>
<br>> Key: JDO-583
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-583" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-583</a><br>> Project: JDO
<br>> Issue Type: Bug
<br>> Components: tck2, tck2-legacy
<br>> Affects Versions: JDO 2 maintenance release 1
<br>> Reporter: Craig Russell
<br>> Assignee: Michelle Caisse
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>> Attachments: SignatureVerifier.patch
<br>>
<br>>
<br>> RAT reveals files that need Apache license headers:
<br>> jdo2-tck-2.1/src/conf/jdo-2_1-signatures.txt
<br>> jdo2-tck-2.1/src/java/org/apache/jdo/tck/pc/company/ CompanyFactoryNewInstance.java
<br>> jdo2-tck-2.1/src/uml/org/apache/jdo/tck/pc/shoppingcart/ shoppingcart.argo.uml\
<br>> jdo2-tck-legacy-2.1/src/conf/jdo-2_1-signatures.txt
<br>> jdo2-tck-legacy-2.1/src/uml/org/apache/jdo/tck/pc/shoppingcart/ shoppingcart.argo.uml
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19003958[jira] Commented: (JDO-597) PMF : Add "readOnly" setting for better handling of read-only datastores2008-08-15T12:01:46Z2008-08-15T12:01:46ZJIRA jira@apache.org<br> [ <a href="https://issues.apache.org/jira/browse/JDO-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622979#action_12622979" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622979#action_12622979</a> ]
<br><br>Andy Jefferson commented on JDO-597:
<br>------------------------------------
<br><br>The log entry "2) Id "org.apache.jdo.tck.pc.company.Company$Oid: 1" has not determined to the class"
<br>suggests that the OID class (passed in to pm.getObjectById) is not known about, and indeed it is a custom PK class and "Company" has not been mentioned during that PMF2's existence, so no metadata is loaded at that point. Consequently DataNucleus has no way of knowing what (persistable) class this PK class refers to and so cannot find the object. Perhaps if you did a pm.getExtent(Company.class) first (to give the implementation knowledge and hence load the metadata) then it would get the object from the id
<br><div class='shrinkable-quote'><br>> PMF : Add "readOnly" setting for better handling of read-only datastores
<br>> ------------------------------------------------------------------------
<br>>
<br>> Key: JDO-597
<br>> URL: <a href="https://issues.apache.org/jira/browse/JDO-597" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-597</a><br>> Project: JDO
<br>> Issue Type: New Feature
<br>> Components: api2, api2-legacy, specification
<br>> Reporter: Andy Jefferson
<br>> Assignee: Andy Jefferson
<br>> Fix For: JDO 2 maintenance release 2
<br>>
<br>> Attachments: JDOReadOnlyException.patch
<br>>
<br>>
<br>> A user has a datastore that is outside their control and they either don't have permission to write to it, or maybe they have permissions but don't want to write to it. They want a better way of handling this, preventing updates to the datastore.
<br>> Propose :-
<br>> PMF property (with setter/getter)
<br>> javax.jdo.option.ReadOnly - values true | false
<br>> JDOReadOnlyException extends JDOUserException
<br>> Behaviour :-
<br>> When readOnly is set to true :-
<br>> Any operation resulting in a creation/modification of an object to be sent to the datastore should throw a JDOReadOnlyException. This may be at commit(), flush(), or alternatively at makePersistent() when using datastore txns, or query.deletePersistentAll(). That is, no change should be made to the datastore contents at all.
</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://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19003832Re: ServiceLoader for JDO PersistenceManagerFactory2008-08-15T11:51:16Z2008-08-15T11:51:16ZCraig L RussellHere's the proposed text for the specification update:
<br><br><proposed>
<br>The PersistenceManagerFactory implementation class must implement a no-
<br>args constructor. This allows the standard Java 6 service discovery
<br>implementation to create a factory instance upon which the
<br>getPersistenceManagerFactory methods can be invoked.
<br></proposed>
<br><br>Craig
<br><br>On Aug 15, 2008, at 11:37 AM, Craig L Russell wrote:
<br><div class='shrinkable-quote'><div class='shrinkable-quote'><br>> Re: <a href="https://issues.apache.org/jira/browse/JDO-556" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-556</a><br>>
<br>> In order to implement this feature, we will need to require that an
<br>> implementation support a public constructor of the implementation
<br>> class so that the getPersistenceManager(Map) and (Map, Map) can be
<br>> invoked on the factory.
<br>>
<br>> I'd like to propose that we update the specification to include this
<br>> requirement. Any objections?
<br>>
<br>> [The RI currently supports this feature, although there are no tests
<br>> for it.]
<br>>
<br>> Craig
<br>>
<br>> Craig L Russell
<br>> Architect, Sun Java Enterprise System <a href="http://java.sun.com/products/jdo" target="_top" rel="nofollow">http://java.sun.com/products/jdo</a><br>> 408 276-5638 mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19003832&i=0" target="_top" rel="nofollow">Craig.Russell@...</a>
<br>> P.S. A good JDO? O, Gasp!
<br>>
</div></div>Craig L Russell
<br>Architect, Sun Java Enterprise System <a href="http://java.sun.com/products/jdo" target="_top" rel="nofollow">http://java.sun.com/products/jdo</a><br>408 276-5638 mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19003832&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://www.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (3K) <a href="http://www.nabble.com/attachment/19003832/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://www.nabble.com/JDO---Development-f23351.html" embed="fixTarget[23351]" target="_top" >JDO - Development</a></p>tag:www.nabble.com,2006:post-19003646ServiceLoader for JDO PersistenceManagerFactory2008-08-15T11:37:02Z2008-08-15T11:37:02ZCraig L RussellRe: <a href="https://issues.apache.org/jira/browse/JDO-556" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/JDO-556</a><br><br>In order to implement this feature, we will need to require that an
<br>implementation support a public constructor of the implementation
<br>class so that the getPersistenceManager(Map) and (Map, Map) can be
<br>invoked on the factory.
<br><br>I'd like to propose that we update the specification to include this
<br>requirement. Any objections?
<br><br>[The RI currently supports this feature, although there are no tests
<br>for it.]
<br><br>Craig
<br><br>Craig L Russell
<br>Architect, Sun Java Enterprise System <a href="http://java.sun.com/products/jdo" target="_top" rel="nofollow">http://java.sun.com/products/jdo</a><br>408 276-5638 mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=190