[jira] [Updated] (JDO-749) Support for java.time types, and querying using associated methods
[ https://issues.apache.org/jira/browse/JDO-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bouschen updated JDO-749: - Fix Version/s: JDO 3.2 > Support for java.time types, and querying using associated methods > -- > > Key: JDO-749 > URL: https://issues.apache.org/jira/browse/JDO-749 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson > Fix For: JDO 3.2 > > > Refer to an associated issue for JPA for what support should look like > https://java.net/jira/browse/JPA_SPEC-63 > The methods that should be supported in queries would initially be > LocalDateTime : getDayOfMonth, getMonth, getYear, getHour, getMinute, > getSecond > LocalTime : getHour, getMinute, getSecond > LocalDate : getDayOfMonth, getMonth, getYear > These would need to be part of JDOQL string-based, as well as the > JDOQLTypedQuery (hence have equivalent Expression classes). > Note that all of these are already implemented in DataNucleus, and there are > JDOQLTypedQuery expression classes available. > Timing of this simply depends on the JRE that the next release of JDO is > targetted at, since this needs Java 8. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-747:
Attachment: StateTransitions.java
StateTransitionPatch_JDO747.txt
I created a patch for the StateTransitions test. As expected, it currently
fails with a number of different errors, but I hope that the tests are correct.
I didn't modify the StateTransitionsReturnedObjects, as refresh() usually does
not return anything.
I couldn't find the optimistic tests with conflicts, except one for
non-transactional commit. Could you point them out to me?
> Behavior of delete() with multiple concurrent Transactions
> --
>
> Key: JDO-747
> URL: https://issues.apache.org/jira/browse/JDO-747
> Project: JDO
> Issue Type: Improvement
> Components: specification
>Affects Versions: JDO 3.1
>Reporter: Tilmann Zäschke
>Priority: Minor
> Labels: concurrency, delete, documentation, refresh(),
> specification
> Fix For: JDO 3.2
>
> Attachments: StateTransitionPatch_JDO747.txt, StateTransitions.java
>
>
> In the Spec I could not find any statement regarding on how a transaction
> should behave if an object is deleted in a different concurrent transaction.
> Related Sections are Section 5.8 (how different methods should behave for
> different object states) and Section 12.6.1 (the behavior of refresh() and
> related methods).
> For example I wonder about the following situations. Suppose I have two
> optimistic sessions, pm1 and pm2, both access the same object. pm1 deletes
> the object and commits. Then what happens in pm2 if:
> 1. pm2 deletes the object and tries to commit, should that work? It's
>wouldn't be a real conflict if both delete it.
> 2. pm2 modifies the object (make dirty) and calls {{refresh()}}. Should I
>get an {{ObjectNotFound}} exception?
> 3. pm2 deletes the object and calls {{refresh()}}. According to the spec,
>{{refresh()}} should not change the object's state. But should it
>still fail with {{ObjectNotFound}}? If refresh should fail, how can I
>ever recover from such a situation, because I can't undelete the
>object?
> Is there a common understanding how this should work?
> IF there an external definition JDO relies on, then I think a reference to an
> external document might useful.
> If not, should the Spec define concurrent behavior?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JDO-483) Add JDOHelper.isLoaded methods
[ https://issues.apache.org/jira/browse/JDO-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004516#comment-15004516 ] Michael Bouschen commented on JDO-483: -- I changed my mind. Suppose you have a detached Object and use a generic method to create a different representation of that Object (e.g. JSON). The application code makes sure that all the neccessary fields are loaded. That generimethod uses reflection to get all the field values, but it needs a way to figure out which fields are loaded and should be included in the representation and which fields should not be touched. So I think it makes sense to have a method JDOHelper.isLoaded. > Add JDOHelper.isLoaded methods > -- > > Key: JDO-483 > URL: https://issues.apache.org/jira/browse/JDO-483 > Project: JDO > Issue Type: Improvement > Components: api, api2-legacy >Affects Versions: JDO 2 maintenance release 1 (2.1) >Reporter: Matthew T. Adams > Fix For: JDO 3.2 > > > I'm putting forth a proposal to add a method to JDOHelper that allows users > to determine whether or not a given object's field is loaded. There are two > options to handle implementations that won't/can't support loaded field > checking, especially when detached (essentially binary compatible v. > non-binary compatible implementations). Option A adopts an approach that > uses Boolean objects instead of primitives, leaving null as a return value > for implementations that won't/can't support it. Option B takes an > exception-based approach and uses boolean primitives. I'm not sure which I > prefer; let's discuss. > > > > JDOHelper > > Checking whether fields are loaded > > In some use cases, an application may need to know whether or not a given > field is loaded, for example when marshaling data from detached objects to > data transfer objects (DTOs). > > Transient fields > > Transient fields are always considered loaded. > > Implementation support > > Some implementations may not be able to support the ability to check the > loaded status of a field, especially when the object is detached. If the > implementation does not support checking whether a field is loaded, then it > must return null from the isLoaded methods. > > Boolean isLoaded(String fieldName, Object pc); > > If the field in the most-derived class of the given object's class identified > by the given name is loaded in the given object, Boolean.TRUE is returned. > If the field is not loaded, Boolean.FALSE is returned. If the given field > name is not declared by the given object's class or its direct or indirect > superclasses, then JDOUserException is thrown. If the implementation does > not support checking the loaded state of a field, null is returned. This > method is equivalent to calling isLoaded(fieldName, pc, pc.getClass()); > > Boolean isLoaded(String fieldName, Object pc, Class c); > > This method exists to support the case where a class hides fields defined in > a superclass and an application wants to determine the loaded state of the > field in the superclass. In most cases, the given Class, c, will be > identical to the class of the given object, pc (that is, c == pc.getClass() > will return true). If the class of the given object, pc, is a subclass of > the given Class, c, then the loaded state of the field defined on c is given. > If the given Class c is not identical to the class of or a superclass of the > given object, pc, then JDOUserException is thrown. If the given Class > represents an interface, then JDOUserException is thrown. > > If the field of the given class is loaded, Boolean.TRUE is returned. If the > field is not loaded, Boolean.FALSE is returned. If the implementation does > not supporting checking the loaded state of a field, null is returned. > > > > > > JDOHelper > > Checking whether fields are loaded > > In some use cases, an application may need to know whether or not a given > field is loaded, for example, when marshaling data from detached objects to > data transfer objects (DTOs). > > Transient fields > > Transient fields are always considered loaded. > > Implementation support > > Some implementations may not be able to support the ability to check the > loaded status of a field, especially when the object is detached. If the > implementation does not support checking whether a field is loaded, then it > must throw JDOUnsupportedOperationException from the isLoaded methods. > > boolean isLoaded(String fieldName, Object pc); > > If the field in the most-derived class of the given object's class identified > by the given name is loaded in the given object, true is returned, otherwise > false is returned. If the given field name is not defined by the given > object's class or its direct or
[jira] [Commented] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004345#comment-15004345
]
Craig L Russell commented on JDO-747:
-
@Tillmann What I intended with optimistic test is a new test that would verify
that your use case actually works. So it would not work now (like your updated
tests) but would work once the state transitions were implemented.
> Behavior of delete() with multiple concurrent Transactions
> --
>
> Key: JDO-747
> URL: https://issues.apache.org/jira/browse/JDO-747
> Project: JDO
> Issue Type: Improvement
> Components: specification
>Affects Versions: JDO 3.1
>Reporter: Tilmann Zäschke
>Priority: Minor
> Labels: concurrency, delete, documentation, refresh(),
> specification
> Fix For: JDO 3.2
>
> Attachments: StateTransitionPatch_JDO747.txt, StateTransitions.java
>
>
> In the Spec I could not find any statement regarding on how a transaction
> should behave if an object is deleted in a different concurrent transaction.
> Related Sections are Section 5.8 (how different methods should behave for
> different object states) and Section 12.6.1 (the behavior of refresh() and
> related methods).
> For example I wonder about the following situations. Suppose I have two
> optimistic sessions, pm1 and pm2, both access the same object. pm1 deletes
> the object and commits. Then what happens in pm2 if:
> 1. pm2 deletes the object and tries to commit, should that work? It's
>wouldn't be a real conflict if both delete it.
> 2. pm2 modifies the object (make dirty) and calls {{refresh()}}. Should I
>get an {{ObjectNotFound}} exception?
> 3. pm2 deletes the object and calls {{refresh()}}. According to the spec,
>{{refresh()}} should not change the object's state. But should it
>still fail with {{ObjectNotFound}}? If refresh should fail, how can I
>ever recover from such a situation, because I can't undelete the
>object?
> Is there a common understanding how this should work?
> IF there an external definition JDO relies on, then I think a reference to an
> external document might useful.
> If not, should the Spec define concurrent behavior?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: JDO TCK Conference Call Friday November 13, 9 am Pacific Daylight Time (PDT)
Attendees: Michael Bouschen, Craig Russell NOTE: Next week’s meeting is canceled. Next meeting will be 9AM Black Friday November 27. Agenda: 1. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to prepare JCP Change Log 2. JIRA JDO-483 "Add JDOHelper.isLoaded methods" https://issues.apache.org/jira/browse/JDO-483 Michael has a use case for this: serializing (JSON) detached objects. AI update the JIRA. 3. Metadata classes for typesafe queries JDO-652 https://issues.apache.org/jira/browse/JDO-652 Need more discussion. AI read the JIRA and follow the links to see what is already implemented. 4. Java8 date/time types JDO-749 https://issues.apache.org/jira/browse/JDO-749 Looks like this can be included in JDO 3.2. Needs spec update and tck tests. 5. Other issues https://issues.apache.org/jira/browse/JDO-747 patch needs review. Once the patch is reviewed and checked in, the tck would fail until the reference implementation was updated. Action Items from weeks past: [Oct 30 2015] AI Craig: File a maintenance review with JCP [May 15 2015] AI Craig Spec change for roll back an active transaction when closing a persistence manager (JDO-735) [Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP Maintenance Release for JDO 3.1 is published [Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL datastores": https://issues.apache.org/jira/browse/JDO-651? [Feb 28 2014] AI Everyone: take a look at https://issues.apache.org/jira/browse/JDO-712 [Feb 28 2014] AI Everyone: take a look at https://issues.apache.org/jira/browse/JDO-625 [Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as persistent field types [Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about JDOHelper methods. In process. 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!
