Apache JDO Project - [jira] Created: (JDO-425) Support for non binary compatibility

This is Interesting: Free IT Magazines  
Home > Archive > Apache JDO Project > September 2006 > [jira] Created: (JDO-425) Support for non binary compatibility





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author [jira] Created: (JDO-425) Support for non binary compatibility
Ilan Kirsh (JIRA)

2006-09-13, 7:11 am

Support for non binary compatibility "reflection based" JDO implementations
----------------------------------------------------------------------------

Key: JDO-425
URL: http://issues.apache.org/jira/browse/JDO-425
Project: JDO
Issue Type: Improvement
Components: specification, tck20
Reporter: Ilan Kirsh


In order to support non binary compatibility JDO implementations that do not have control on each field access (reflective implementations) the following tests that are based on immediate field access tracking have to be modified:

1. IsTransactionalFalse.testIsTransactionalFalse (field access in line 86 is not detected immediately)
2. MakeTransactionalPriorToTransactionRolle
dback.testTransactionalInst (field modifications in lines 115, 117 are not detected immediately)
3. InstanceLifecycleListenerLoad.testLoad (field access in line 101 is not detected immediately)
4. NoAccessToFieldsAfterPredelete.test (field access in line 115, for instance, is not detected immediately)
5. StateTransitions.test (operations in lines 472-496 are not detected immediately)
6. WhenNontransactionalReadIsFalse.test (field access in line 116, for instance, is not detected immediately)

Accordingly the specification should be updated in a way that state transitions, exceptions and events that are based on immediate field access tracking should be optional or more flexible in timing, at least for non binary compatibility implementations.
For instance, the events firePreDirty and firePostDirty may be fired only when it is detected the an object became dirty in the following call to isDirty, commit or flush (this for example does not require changing the TCK).

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com