RE: Problem with self-referencing relationship
Not from me too. I'm VERY busy in my FULL time job. I will come back later this week. Erik Bengtson -Original Message- From: Andy Jefferson [mailto:[EMAIL PROTECTED] Sent: Monday, August 08, 2005 8:31 PM To: jdo-dev@db.apache.org Subject: Re: Problem with self-referencing relationship Any update on this? Not from me. Not had time to look at it. Don't know if Erik has. Out of interest, how do I run this CompletenessTest on its own ? (since it's not in alltests.conf). I've tried running companyNoRelationships.conf, which is fine for 1 run, but if I run it again it tries to insert the same data again and causes duplicate key issues. Tests should be cleaning themselves out so they leave the datastore in the same state as it was at startup (IMHO). -- Andy
Re: Inheritance proposal
Hi, I discussed the inheritance proposal with Michael today and we came up with a couple of questions I added below. The following table describes the inheritance strategy setting for each class for the 5 inheritance mappings. I abbreviated the inheritance strategies: new - new-table, super - superclass-table, sub- subclass-table. ClassMapping0 Mapping1 Mapping2 Mapping3 Mapping4 - Person new new new new new Employee super new ? sub new FullTimeEmployee super new new new super PartTimeEmployee super new new new super Insurance new new ? sub new DentalInsurancesuper new new new super MedicalInsurance super new new new super Questions: - What is a reasonable inheritance strategy for the abstract classes Employee and Insurance in Mapping2? The mapping does not define a table for the abstract classes, so new-table does not make sense. I see two options: either subclass-table or the abstract class does not define an inheritance strategy at all. - Does JDO require a inheritance element for classes in an inheritance hierarchy? If not, is there a default? The same questions apply to the strategy attribute inside of the inheritance element. - Can I figure out whether inherited fields are mapped to the superclass or subclass table by just looking at the inheritance strategy? I think the answer is no, correct? So is it the existence of the nested join elements that determines only declared fields are mapped? Mapping1 and Mapping2 have this difference. Mapping1 maps only declared field where Mapping2 uses tables for all the fields (including inherited fields) per class. Regards Michael Hi, in t-conference, Jul 8, Craig proposed 5 inheritance mappings that TCK should implement. Below, you find a description of each mapping. All mappings are based on the company model. The company model defines two inheritance hierarchies: PersonInsurance | /\ EmployeeDentalInsurance MedicalInsurance / \ FullTimeEmployee PartTimeEmployee The proposal is to define a separate schema and separate ORM metadata for each mapping. Each mapping below specifies the ORM inheritance strategy for each class. Note, that the first mapping (Mapping 0) is already implemented by TCK: - Mapping 0 (implemented by TCK): The same table for all classes in the inheritance hierarchy. That table specifies a discriminator column, identiying the actual type of each row. Person and Insurance have inheritance strategy new-table. Tables of these classes have dicriminator columns. All other classes have inheritance strategy superclass-table. - Mapping 1: Separate table for each class in the inheritance hierarchy. Each table contains columns for the declared fields. There are no discriminator columns. Instead, there are FKs from subclass tables to superclass tables. The ORM metadata specifies nested join elements for all subclasses. All classes have inheritance strategy new-table. - Mapping 2: Separate table for each class in the inheritance hierarchy. No tables for abstract classes Employee and Insurance. Each table contains columns for all fields including fields of superclasses. There are no FKs from subclass tables to superclass tables. The ORM metadata does not specifies nested join elements. There are no discriminator columns. All classes have inheritance strategy new-table. Some additional constraints: Managers, mentors, hradvisors, and employees of the month are fulltime employees. Only fulltime employees can have insurances, can be project members, and can be project reviewers. Separate phone number type tables for persons, fulltime employees, and parttime employees. - Mapping 3: Person has inheritance strategy new-table. Employee has inheritance strategy subclass-table. PartTimeEmployee and FullTimeEmployee have inheritance strategy new-table. Insurance has inheritance strategy subclass-table. MedicalInsurance and DentalInsurance have inheritance strategy new-table. The ORM metadata specifies nested join elements for classes PartTimeEmployee and FullTimeEmployee. Tables of these classes have FKs to table of class Person. There are no discriminator columns. - Mapping 4: Person, Employee, and Insurance have inheritance strategy new-table. PartTimeEmployee, FullTimeEmployee, MedicalInsurance, and DentalInsurance have inheritance strategy superclass-table. The ORM metadata specifies a nested join element for class Employee. The table of class Employee has a FK to the table of class Person. The tables of classes Employee and Insurance have discriminator columns.
Patch for Detachable, PersistenceCapable, StateManager
For the benefit of anyone developing the TCK and thinking about using the latest API20 (with yesterdays changes) when running with JPOX : It won't work with current latest build of JPOX (so stick to your existing jdo2-api-2.0-SNAPSHOT.jar) JPOX CVS has now been updated and the next nightly build (jpox-SNAPSHOT.jar, jpox-enhancer-SNAPSHOT.jar), dated 10/08/2005, will support the latest API20 changes. -- Andy Java Persistent Objects - JPOX
Re: Inheritance proposal
Hi Michael(s), Not fully read your proposal, so can't comment on the rest ... - Does JDO require a inheritance element for classes in an inheritance hierarchy? If not, is there a default? The same questions apply to the strategy attribute inside of the inheritance element. You don't need to specify it. The default (strategy) is * If the class has no persistence capable superclass, use new-table * If the class has a persistence capable superclass, use superclass-table - Can I figure out whether inherited fields are mapped to the superclass or subclass table by just looking at the inheritance strategy? I think the answer is no, correct? Yes you can. The inheritance always has a strategy (see default above), so you know where the field will be persisted. I *believe* that the inheritancejoin is only for specifying the names of the primary key columns in app identity cases. Perhaps there's some other use for it that I don't know of ? -- Andy
Running a single test in fostore20 (was Re: Problem with self-referencing relationship)
Hi, [...] I heard you mentioning on the conference call that i could run an individual test in maven, could you please tell me how to do that? It depends on which project you're running. The TCK can run a single configuration (combination of database, test data, and test program. In the tck20 directory maven help should give you the details. If you're in the fostore20 project, it's a work in progress. I don't see any way to run a single test. That would be a good thing to add to the maven.xml. Something like a system property so you could do: maven has some builtin support to run JUnit tests (it is the Maven Test Plug-in). The build goal uses this plugin to run all the specified JUnit tests. The plugin provides a goal test:single to run a single which can be used in the fostore20 subproject: maven -Dtestcase=org.apache.jdo.test.Test_EmpDeptAppId test:single Please note, this does not work in the tck20 subproject, since it runs configurations not single test cases. Regards Michael maven -Djdo.test.name=org.apache.jdo.test.Test_EmpDeptAppId run.single My fostore20 tests are all having errors? Is anybody else facing the same problems with fostore20 (i hope its nothing to do with file permissions or something-- but my guess is that should result in failures instead of errors) I checked in a fix for FOStorePMF and StateManagerImpl to meet the JDO2 requirements this afternoon. When I run fostore20 now, I just get one error related to the new jdoNewObjectIdInstance that changed between JDO1 and JDO2. Running org.apache.jdo.test.Test_EmpDeptAppId [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 10.737 sec [junit] [ERROR] TEST org.apache.jdo.test.Test_EmpDeptAppId FAILED Craig On 8/8/05, Craig Russell [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Andy, Karan, On Aug 8, 2005, at 11:30 AM, Andy Jefferson wrote: Any update on this? Not from me. Not had time to look at it. Don't know if Erik has. Out of interest, how do I run this CompletenessTest on its own ? (since it's not in alltests.conf). I've tried running companyNoRelationships.conf, which is fine for 1 run, but if I run it again it tries to insert the same data again and causes duplicate key issues. Tests should be cleaning themselves out so they leave the datastore in the same state as it was at startup (IMHO). I completely agree. Please file a JIRA on this issue. CompletenessTest didn't get the message about cleaning up after itself. ;-) Karan, This is probably a good way to learn about one of the main components of our O/R mapping test framework. Craig -- Andy Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! -- Karan Malhi 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! -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Inheritance proposal
Hi Andy, Hi Michael(s), Not fully read your proposal, so can't comment on the rest ... - Does JDO require a inheritance element for classes in an inheritance hierarchy? If not, is there a default? The same questions apply to the strategy attribute inside of the inheritance element. You don't need to specify it. The default (strategy) is * If the class has no persistence capable superclass, use new-table * If the class has a persistence capable superclass, use superclass-table You are right, I overlooked the default specification in chapter 15.7. - Can I figure out whether inherited fields are mapped to the superclass or subclass table by just looking at the inheritance strategy? I think the answer is no, correct? Yes you can. The inheritance always has a strategy (see default above), so you know where the field will be persisted. I *believe* that the inheritancejoin is only for specifying the names of the primary key columns in app identity cases. Perhaps there's some other use for it that I don't know of ? Suppose there are two non-abstract persistence-capable classes A and B. Class B extends A. Both explicitly define the inheritance strategy new-table. Class A maps to table TA and B maps to table TB. Then there are still two scenarios possible, depending on where to store the inherited fields of B instances: (1) In table TA. Then we need a join element, since a class B instance is represented by a row in table TA and a row in table TB. (2) In table TB. No join element is needed since TB includes columns for the inherited fields. So TA only has rows for class A instances, not for B instances. Regards Michael -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Problem with self-referencing relationship
Hi Andy, I can run companyNoRelationships.conf several times without reinstalling the schema. The result is always the same: SQL Exception: Column name 'DATASTOREIDENTITY0.PERSONS.DATASTORE_IDENTITY' is in more than one table in the FROM list. This is JDO-93. I cannot reproduce JDO-116. Have there been any other exceptions when you ran companyNoRelationships.conf the first time? Regards, Michael Any update on this? Not from me. Not had time to look at it. Don't know if Erik has. Out of interest, how do I run this CompletenessTest on its own ? (since it's not in alltests.conf). I've tried running companyNoRelationships.conf, which is fine for 1 run, but if I run it again it tries to insert the same data again and causes duplicate key issues. Tests should be cleaning themselves out so they leave the datastore in the same state as it was at startup (IMHO). -- --- Michael Watzek [EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]Buelowstr. 66 Tel.: ++49/30/235 520 36 10783 Berlin - Germany Fax.: ++49/30/217 520 12 http://www.spree.de/ ---
Re: Inheritance proposal
Suppose there are two non-abstract persistence-capable classes A and B. Class B extends A. Both explicitly define the inheritance strategy new-table. Class A maps to table TA and B maps to table TB. Then there are still two scenarios possible, depending on where to store the inherited fields of B instances: (1) In table TA. Then we need a join element, since a class B instance is represented by a row in table TA and a row in table TB. (2) In table TB. No join element is needed since TB includes columns for the inherited fields. So TA only has rows for class A instances, not for B instances. Hi Michael, that's not our interpretation of the spec :-) In your example if both classes have new-table then we have the fields specified in class A persisted into table TA, and the fields specified in class B persisted into table TB - so option 1 (ONLY), and we do not need any join unless wanting to override the join column names (pk columns). An instance of B will have a row in TA, and an associated row in TB. An instance of A will have a row in TA only. The only difference we see from option 1 is where the user decides to override the field specifications for a field of A, in class B e.g class name=B field name=A.field1/ /class which would mean that table TB will carry the value for that field (rather than the column in table TA). -- Andy Java Persistent Objects - JPOX
Re: Problem with self-referencing relationship
I can run companyNoRelationships.conf several times without reinstalling the schema. The result is always the same: Hi Michael, I get the same as you, today! but certainly didn't yesterday. Since I can't reproduce it myself now, someone please just close the issue (JIRA-116) and if I find what was causing it I'll re-raise it with clearer instructions :-) On an unrelated note, can someone please add the following 2 lines to test/conf/logging.properties log4j.category.com.mchange.v2.c3p0=INFO, A1 log4j.category.com.mchange.v2.resourcepool=INFO, A1 These will mean that the message on the console :- log4j:WARN No appenders could be found for logger (com.mchange.v2.log.MLog). log4j:WARN Please initialize the log4j system properly. when running the TCK (coming from C3P0) will not appear. -- Andy
Re: Inheritance proposal
Hi Andy, thanks for the info! You are right, I forgot that I have the add field elements for the inherited fields. Regards Michael Suppose there are two non-abstract persistence-capable classes A and B. Class B extends A. Both explicitly define the inheritance strategy new-table. Class A maps to table TA and B maps to table TB. Then there are still two scenarios possible, depending on where to store the inherited fields of B instances: (1) In table TA. Then we need a join element, since a class B instance is represented by a row in table TA and a row in table TB. (2) In table TB. No join element is needed since TB includes columns for the inherited fields. So TA only has rows for class A instances, not for B instances. Hi Michael, that's not our interpretation of the spec :-) In your example if both classes have new-table then we have the fields specified in class A persisted into table TA, and the fields specified in class B persisted into table TB - so option 1 (ONLY), and we do not need any join unless wanting to override the join column names (pk columns). An instance of B will have a row in TA, and an associated row in TB. An instance of A will have a row in TA only. The only difference we see from option 1 is where the user decides to override the field specifications for a field of A, in class B e.g class name=B field name=A.field1/ /class which would mean that table TB will carry the value for that field (rather than the column in table TA). -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Antlr 2.7.5
Hi, I changed the antlr dependency to version 2.7.5, because this version is available on ibiblio. So there is no need anymore to manually copy the antlr jar to the local maven repository. Regards Michael Hi Brian, hi Craig, as Craig pointed out, we had a non-standard way to support international characters when we used antlr 2.7.0. But I changed this when we moved to antlr 2.7.3. So I think it makes sense to switch to antlr 2.7.5. I will work on this, I also like to switch the ri11 project and then update the Readme. Brian, did you try to switch and ran into specific problems? I tried it and it seems to work. Today a lot of tests in fostore20 fail, but this is due to a api20 change. I will fix this first and then switch antlr. Regards Michael Hi Brian, On Aug 5, 2005, at 10:15 AM, Brian McCallister wrote: Any reason we are using antlr 2.7.3 and fighting maven? We coul djust go to 2.7.5 which is in the repo... We added international character support in a non-standard way in 2.7.0 and have had to carry it forward through a few releases. Each release had its own set of problems. Michael Bouschen is the expert who can tell us whether and how we can use the latest release. Craig -Brian 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! -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Cleaning up the datastore in tearDown
Minor point, but I would suggest doing it in setUp() for a couple reasons: * You know datastore is in good state before test runs instead of after * You can examine datastore state afterwards to double check things manually * If things go wrong during the test, the evidence isn't erased On Aug 9, 2005, at 5:51 PM, Craig Russell wrote: Hi, I'm thinking a better way of cleaning up might be: Extent toBeDeleted = pm.getExtent(parameterClass, false); Query toBeDelete = pm.newQuery(parameterClass, toBeDeleted); toBeDelete.deletePersistentAll(); This doesn't require that the query be executed except for the purposes of calling the jdoPreDelete callback, which is not an issue in the TCK. Does JPOX support this? Would it help (I'm thinking of the issue with CompletenessTest not cleaning up because of issues with loading the instances). Craig 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!
