[
http://issues.apache.org/jira/browse/JDO-306?page=comments#action_12366594 ]
Andy Jefferson commented on JDO-306:
JPOX CVS has the new methods. The latest nightly build should be fine.
> Add makeTransient(Object, boolean) to PersistenceManager
> -
[ http://issues.apache.org/jira/browse/JDO-306?page=all ]
Craig Russell updated JDO-306:
--
Attachment: makeTransient.patch
I cleaned up the javadoc just a bit. I'm ready to check in as soon as JPOX is
ready with the new methods.
> Add makeTransient(Object
[ http://issues.apache.org/jira/browse/JDO-307?page=all ]
Craig Russell resolved JDO-307:
---
Resolution: Fixed
svn commit -m "JDO-307 update javadoc for FetchPlan.getGroups"
src/java/javax/jdo/FetchPlan.java
Sendingsrc/java/javax/jdo/FetchPlan.
I'd second the motion that the TCK ORM should use native instead of
identity. It's the default, so we can just remove the strategy entirely.
Craig
On Feb 15, 2006, at 1:20 PM, Michael Bouschen wrote:
Hi Michael,
would it make sense if the TCK ORM files for datastore identity use
the strat
[
http://issues.apache.org/jira/browse/JDO-288?page=comments#action_12366581 ]
Craig Russell commented on JDO-288:
---
Changes look good. I've committed them.
svn commit -m "JDO-288 update dtd, xsd, FetchPlan for spec changes"
src/java/javax/jdo/FetchPlan.j
Update FetchPlan.getGroups javadoc to reflect the spec
--
Key: JDO-307
URL: http://issues.apache.org/jira/browse/JDO-307
Project: JDO
Type: Task
Components: api20
Versions: JDO 2 beta
Reporter: Erik
Hi Michael,
would it make sense if the TCK ORM files for datastore identity use the
strategy "native" instead of "identity"?
Regards Michael
Hi Craig,
the run rules state, that the .orm files must not be changed by JDO
vendors.
The ORM for datastore identity specifies strategy "identity"
[
http://issues.apache.org/jira/browse/JDO-288?page=comments#action_12366540 ]
Andy Jefferson commented on JDO-288:
Hi Michael,
JPOX CVS has those methods. Check in at will. The latest downloadable JPOX
nightly build has an error in the scope of some of
[ http://issues.apache.org/jira/browse/JDO-306?page=all ]
Andy Jefferson updated JDO-306:
---
Attachment: pm_patch_2.txt
Second patch - this replaces the first one, and specifies the
makeTransient(Collection, boolean), makeTransient(Object[], boolean) method
[
http://issues.apache.org/jira/browse/JDO-288?page=comments#action_12366536 ]
Michael Bouschen commented on JDO-288:
--
Hi Andy,
the patch looks good to me. Does the latest JPOX version already implement the
new FetchPlan methods? I could check in the
Hi Andy,
Thanks for filing and fixing this. I'll review it asap.
Craig
On Feb 14, 2006, at 11:50 PM, Andy Jefferson (JIRA) wrote:
[ http://issues.apache.org/jira/browse/JDO-288?page=all ]
Andy Jefferson updated JDO-288:
---
Attachment: patch.txt
Patch f
Hi Erik,
On Feb 15, 2006, at 1:58 AM, [EMAIL PROTECTED] wrote:
Hi,
Is it returning a immutable collection or a collection where
changes will not
affect the FetchPlan?
My version of the spec sez:
/** Return an immutable Set of the names of all active fetch groups. */
Set getGroups();
It'
Hi Andy,
Yes, you are right. I accidentally omitted this from the draft.
I'll add all three methods:
void makeTransient(Object pc, boolean useFetchPlan);
void makeTransient(Collection pcs, boolean useFetchPlan);
void makeTransient(Object[] pcs, boolean useFetchPlan);
I haven't reviewed your pat
1. should be2. should be3. same as 2 for index4. element update-action should restrict the permitted values to the same values as foreign-key update-action5. Missing element key attribute update-action6. Missing element value attribute update-action7. Element order should not have the delete-action
Hi Michael,Here is the close-to-final test case for the xsd. Check it out.Thanks,Craig
Positive99-xsd.jdo
Description: Binary data
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Desc
Hi Wes,
Since an association has no identity, I would expect Collection.equals using JDO
identity of the elements and owner, meaning 1 result.
IMO, we don't have to define these semantics unless they are going to be set in
the spec.
Regards,
Erik Bengtson
Quoting Wes Biggs <[EMAIL PROTECTED]>:
I still contend that "distinct" does not imply the .equals() operator,
and thus the answer would be
Collection1 [emp1,emp2,emp3]
Collection2 [emp1,emp2,emp3]
Where Collection1 != Collection2 even though
Collection1.equals(Collection2).
Consider an employee database with two men named John Smi
[ http://issues.apache.org/jira/browse/JDO-306?page=all ]
Andy Jefferson updated JDO-306:
---
Attachment: pm_patch.txt
Patch for api20/src/java/javax/jdo/PersistenceManager.java
> Add makeTransient(Object, boolean) to PersistenceManager
> ---
Add makeTransient(Object, boolean) to PersistenceManager
Key: JDO-306
URL: http://issues.apache.org/jira/browse/JDO-306
Project: JDO
Type: Task
Components: api20
Versions: JDO 2 beta
Reporter: A
19 matches
Mail list logo