Hello,

the specification currently is somewhat confusing where it defines the
meta-data attributes "dependent" and "element-dependent". Concerning
"dependent" it says:

"The dependent attribute indicates that the field contains a
reference that is to be deleted
from the datastore if the referring instance in which the field is
declared is deleted, or if the
referring field is nullified."

Now does that mean that really the *reference* is to be deleted (which
seems kinda natural to me), or rather the object being referred to?
Probably the latter?

For collection fields, there is the additional "dependent-element"
attribute of the "collection" tag. Wouldn't it be enough to have
"dependent" on the field level? Or what does it mean if the user
specifies 'dependent="false"' with nested 'element-dependent="true"', or
vice-versa?

Thanks for any explanations,
Jörg

--
 ________________________________________
__________________
Dipl.-Inf. Jörg von Frantzius  |            artnology GmbH
|                Milastr. 4
Tel +49 (0)30 4435 099 26      |              10437 Berlin
Fax +49 (0)30 4435 099 99      |  http://www.artnology.com
 _______________________________|________
__________________

[ Post a follow-up to this message ]

Hi Jörg,

On Nov 3, 2005, at 1:49 AM, Jörg von Frantzius wrote:

> Hello,
>
> the specification currently is somewhat confusing where it defines  
> the meta-data attributes "dependent" and "element-dependent".  
> Concerning "dependent" it says:
>
>    "The dependent attribute indicates that the field contains a
>    reference that is to be deleted

The reference is the object that is referenced by the field. I'll try 
to clarify this in the spec.

>    from the datastore if the referring instance in which the field is
>    declared is deleted, or if the
>    referring field is nullified."
>
> Now does that mean that really the *reference* is to be deleted  
> (which seems kinda natural to me), or rather the object being  
> referred to? Probably the latter?

Yes.
>
> For collection fields, there is the additional "dependent-element"  
> attribute of the "collection" tag. Wouldn't it be enough to have  
> "dependent" on the field level?

We try to make the field metadata refer to behavior of the field  
itself, and put the behavior of multi-valued field types (array,  
collection, map) in separate metadata to better match the semantics  
of Collection versus Element.

We could make it illegal to specify dependent on field types of  
array, collection, and map...

> Or what does it mean if the user specifies 'dependent="false"' with  
> nested 'element-dependent="true"', or vice-versa?

See above.

Experts, any opinion on this subject?

Craig
>
> Thanks for any explanations,
> Jörg
>
> -- 
>  ________________________________________
__________________
> Dipl.-Inf. Jörg von Frantzius  |            artnology GmbH
>                               |                Milastr. 4
> Tel +49 (0)30 4435 099 26      |              10437 Berlin
> Fax +49 (0)30 4435 099 99      |  http://www.artnology.com
>  _______________________________|________
__________________
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

[ Post a follow-up to this message ]

Please see my comments below on how JPOX will treat dependent vs.
element-dependent on collection fields. Please reply if you have objections!

Craig L Russell schrieb:
> Hi Jörg,
>
> On Nov 3, 2005, at 1:49 AM, Jörg von Frantzius wrote:
> 
>
> The reference is the object that is referenced by the field. I'll try
> to clarify this in the spec.
> 
>
> Yes. 
>
> We try to make the field metadata refer to behavior of the field
> itself, and put the behavior of multi-valued field types (array,
> collection, map) in separate metadata to better match the semantics of
> Collection versus Element.
>
> We could make it illegal to specify dependent on field types of array,
> collection, and map...
> 
>
> See above.
JPOX will ignore any "dependent" attribute setting on Collection fields,
so only the "element-dependent" attribute will be of meaning for
Collection fields.
>
> Experts, any opinion on this subject?
>
> Craig 
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>


--
 ________________________________________
__________________
Dipl.-Inf. Jörg von Frantzius  |            artnology GmbH
|                Milastr. 4
Tel +49 (0)30 4435 099 26      |              10437 Berlin
Fax +49 (0)30 4435 099 99      |  http://www.artnology.com
 _______________________________|________
__________________

[ Post a follow-up to this message ]

Hi Jörg,

I'm not sure, if the bug is in the area of dependent objects.

The failing configuration is inheritance1 for datastoreidentity. This
configuration executes the completeness test. This test case is
successfully executed by other configuration, e.g. inheritance1 for
applicationidentity, inheritance4 for both identity types, and all
relationship configurations (companyXXX.conf) for both identity types.

I rather think that the problem may be the order of DELETE statements in
the Person hierarchy.

Regards,
Michael
> Please see my comments below on how JPOX will treat dependent vs.
> element-dependent on collection fields. Please reply if you have
> objections!
>
> Craig L Russell schrieb:
> 
>
> JPOX will ignore any "dependent" attribute setting on Collection fields,
> so only the "element-dependent" attribute will be of meaning for
> Collection fields.
> 
>
>


--
-------------------------------------------------------------------
Michael Watzek                  Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de        Buelowstr. 66
Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
Fax.:  ++49/30/217 520 12       http://www.spree.de/
-------------------------------------------------------------------

[ Post a follow-up to this message ]

Hi Michael,

> I'm not sure, if the bug is in the area of dependent objects.

That is the code that was changed. Without it all works fine.

> The failing configuration is inheritance1 for datastoreidentity. This
> configuration executes the completeness test. This test case is
> successfully executed by other configuration, e.g. inheritance1 for
> applicationidentity, inheritance4 for both identity types, and all
> relationship configurations (companyXXX.conf) for both identity types.
>
> I rather think that the problem may be the order of DELETE statements in
> the Person hierarchy.

Yes, but what order ? What statement is out of order with what statement ?
When deletePersistent is called all dependencies are checked and either
nulled (where possible) or deleted (where dependent field is set), before th
e
object is deleted. There is nothing to do with ordering in that process.
Issues like FK constraints failing are likely due to the FK not being
nullable yet not being defined as dependent field.

Do you have some info regarding what this FK is ?
Sadly I've no idea what Derby's nice message
"constraint 'SQL060127010242262' for key (3)"
means. It might have been nice for it to provide a column name ? or a relate
d
table ? but no we get the result of '"SQL" + random()' perhaps

--
Andy

[ Post a follow-up to this message ]

Andy Jefferson schrieb:
> Hi Michael,
>
> 
>
> That is the code that was changed. Without it all works fine.
>
> 
>
> Yes, but what order ? What statement is out of order with what statement ?
> When deletePersistent is called all dependencies are checked and either
> nulled (where possible) or deleted (where dependent field is set), before 
the
> object is deleted. There is nothing to do with ordering in that process.
> Issues like FK constraints failing are likely due to the FK not being
> nullable yet not being defined as dependent field.
>
> Do you have some info regarding what this FK is ?
> Sadly I've no idea what Derby's nice message
> "constraint 'SQL060127010242262' for key (3)"
> means. It might have been nice for it to provide a column name ? or a rela
ted
> table ? but no we get the result of '"SQL" + random()' perhaps
>
My guess is that some owner object is deleted before its owned
collection elements are deleted (because my bug prevents the latter from
being deleted). I don't know why that works with datastore ids, though...

I hope I can give feedback today later on whether the problem goes away
after fixing that bug.


--
 ________________________________________
__________________
Dipl.-Inf. Jörg von Frantzius  |            artnology GmbH
|                Milastr. 4
Tel +49 (0)30 4435 099 26      |              10437 Berlin
Fax +49 (0)30 4435 099 99      |  http://www.artnology.com
 _______________________________|________
__________________

[ Post a follow-up to this message ]

Hi Andy,

> Hi Michael,
>
> 
>
>
> That is the code that was changed. Without it all works fine.
>
> 
>
>
> Yes, but what order ? What statement is out of order with what statement ?
> When deletePersistent is called all dependencies are checked and either
> nulled (where possible) or deleted (where dependent field is set), before 
the
> object is deleted.
That's fine. I just wondered why the problem only shows up for
inheritance1 with datastoreidentity and not for the other configurations
executing the completeness test.

There is nothing to do with ordering in that process.
> Issues like FK constraints failing are likely due to the FK not being
> nullable yet not being defined as dependent field.
>
> Do you have some info regarding what this FK is ?
> Sadly I've no idea what Derby's nice message
> "constraint 'SQL060127010242262' for key (3)"
> means. It might have been nice for it to provide a column name ? or a rela
ted
> table ? but no we get the result of '"SQL" + random()' perhaps
>
It seems that the FK name is generated by Derby. I checked the FK
definitions in schema 1: There are several unnamed FKs in the schema
referencing table 'persons' which may be candidates for the message above:

- persons.manager
- persons.mentor
- persons.hradvisor
- insuranceplans.employee
- employee_phoneno_type.empid

I'll check which one may be the problem and let you know.

Regards

--
-------------------------------------------------------------------
Michael Watzek                  Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de        Buelowstr. 66
Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
Fax.:  ++49/30/217 520 12       http://www.spree.de/
-------------------------------------------------------------------

[ Post a follow-up to this message ]

Hi Andy,

 
> It seems that the FK name is generated by Derby. I checked the FK
> definitions in schema 1: There are several unnamed FKs in the schema
> referencing table 'persons' which may be candidates for the message above:
>
> - persons.manager
> - persons.mentor
> - persons.hradvisor
> - insuranceplans.employee
> - employee_phoneno_type.empid
>
I renamed the FKs above in my local schema. It appears that the problem
occurs on the manager column. Please see below.

Regards,
Michael

[java] ERROR 23503: DELETE on table 'PERSONS' caused a violation of
foreign key constraint 'EMPS_MANAGER' for key (3
).  The statement has been rolled back.
[java]      at
org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
[java]      at
org.apache.derby.impl.sql.execute.ReferencedKeyRIChecker.doCheck(Unknown
Source)
[java]      at
org.apache.derby.impl.sql.execute.RISetChecker.doPKCheck(Unknown Source)
[java]      at
org.apache.derby.impl.sql.execute.DeleteResultSet.collectAffectedRows(Unknow
n
Source)
[java]      at
org.apache.derby.impl.sql.execute.DeleteResultSet.open(Unknown Source)
[java]      at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
[java]      at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
[java]      at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
[java]      at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
[java]      at
com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.execute(NewProxyPreparedS
tatement.java:911)
[java]      at
org.jpox.store.rdbms.request.Request.executeUpdate(Request.java:69)
[java]      at
org.jpox.store.rdbms.request.DeleteRequest.execute(DeleteRequest.java:239)
[java]      at
org.jpox.store.rdbms.table.ClassTable.delete(ClassTable.java:2170)
[java]      at
org.jpox.store.rdbms.table.ClassTable.delete(ClassTable.java:2175)
[java]      at
org.jpox.store.rdbms.table.ClassTable.delete(ClassTable.java:2175)
[java]      at
org.jpox.store.StoreManager.delete(StoreManager.java:794)
[java]      at
org.jpox.state.StateManagerImpl. internalDeletePersistent(StateManagerImp
l.ja
va:4010)
[java]      at
org.jpox.state.StateManagerImpl.deletePersistent(StateManagerImpl.java:3966)
[java]      at
org.jpox.AbstractPersistenceManager. internalDeletePersistent(AbstractPersist

enceManager.java:1342)
[java]      at
org.jpox.AbstractPersistenceManager. deletePersistentAll(AbstractPersistenceM

anager.java:1380)
[java]      at
org.apache.jdo.tck.JDO_Test.deleteTearDownClasses(JDO_Test.java:396)
[java]      at
org.apache.jdo.tck.JDO_Test.localTearDown(JDO_Test.java:318)
[java]      at org.apache.jdo.tck.JDO_Test.tearDown(JDO_Test.java:287)
[java]      at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:234)
[java]      at
org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120)
[java]      at
org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95)

--
-------------------------------------------------------------------
Michael Watzek                  Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de        Buelowstr. 66
Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
Fax.:  ++49/30/217 520 12       http://www.spree.de/
-------------------------------------------------------------------

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

Hi Michelle,

the attached patch is meant as a suggestion for named FKs in the schema.
It changes schema1 and schema4 for datastore identity both. The idea is
to replace all REFERENCES clauses in column definitions by CONSTRAINT
clauses. Furthermore, it also replaces UNIQUE clauses in column
definitions by CONSTRAINT clauses.

Regards,
Michael

Craig L Russell wrote:
> FYI, at the Friday JDO TCK conference call, Michelle volunteered to
> update the schema with user-decipherable foreign key names.
>
> Craig
>
> On Jan 27, 2006, at 8:56 AM, Michael Watzek wrote:
> 
>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>


--
-------------------------------------------------------------------
Michael Watzek                  Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de        Buelowstr. 66
Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
Fax.:  ++49/30/217 520 12       http://www.spree.de/
-------------------------------------------------------------------

Attachment: Schema1Schema4.patch
This has been downloaded 0 time(s).

[ Post a follow-up to this message ]