Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] issues running JPA Test Suite on Symfoware platform 
Hi Tom,
Because of Eclipse Foundation IP rules, in order for EclipseLink to accept a user-submitted patch, it must be attached to a bug in bugzilla. Sorry for any inconvenience this causes. Please feel free to open bugs for each issue you require a patch for and let me know what the bug numbers are.
No problem. I suppose it's better to keep patches and a description for the problems they address together in one place anyway. 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=289019
https://bugs.eclipse.org/bugs/show_bug.cgi?id=289020

I also created bugs for two other issues I mentioned:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=289021
https://bugs.eclipse.org/bugs/show_bug.cgi?id=289023

Could you take care of them?

Thanks,
Dies



Dies Koper wrote:

Hi Tom,
Having said that, it looks like when we output the ddl files, we should probably be doing a platform check. That likely will not cause an issue with the tests as they run on Java SE, but it is a but worth fixing. 

Patch attached.
We should be able to fix the hardcoded drop constraint statements fairly easily. Just let me know which classes are causing issues. 

It might be easier to just do a search for "ALTER TABLE ":
eclipselink.core.test/src/org/eclipse/persistence/testing/framework/LoadBuildSystem.java (4 matches) 96: session.executeNonSelectingCall(new SQLCall("ALTER TABLE RESULT ADD CONSTRAINT FK_RESULT_summaryId FOREIGN KEY (summaryId) REFERENCES SUMMARY (id)")); 97: session.executeNonSelectingCall(new SQLCall("ALTER TABLE RESULT ADD CONSTRAINT FK_RESULT_lbuildId FOREIGN KEY (lbuildId) REFERENCES LOADBUILD (id)")); 98: session.executeNonSelectingCall(new SQLCall("ALTER TABLE SUMMARY ADD CONSTRAINT FK_LOADBUILD_lbuildId FOREIGN KEY (lbuildId) REFERENCES LOADBUILD (id)")); 99: session.executeNonSelectingCall(new SQLCall("ALTER TABLE SUMMARY ADD CONSTRAINT FK_LOADBUILD_parentId FOREIGN KEY (parentId) REFERENCES SUMMARY (id)")); 

models/inheritance/InheritanceSystem.java (6 matches)
121: session.executeNonSelectingSQL("Alter TABLE PROJECT_WORKER_BATCH DROP CONSTRAINT PROJECT_WORKER_BATCH_HD"); 122: session.executeNonSelectingSQL("Alter TABLE PROJECT_BATCH DROP CONSTRAINT PROJECT_WORKER_BATCH_FK"); 123: session.executeNonSelectingSQL("Alter TABLE ALLIGATOR DROP CONSTRAINT FK_ALLIGATOR_VICTIM_ID"); 124: session.executeNonSelectingSQL("Alter TABLE PERSON2 DROP CONSTRAINT PERSON2_PERSON2_FRND"); 125: session.executeNonSelectingSQL("Alter TABLE PERSON2 DROP CONSTRAINT PERSON2_PERSON2_REP"); 126: session.executeNonSelectingSQL("Alter TABLE PERSON2 DROP CONSTRAINT PERSON2_PERSON2_BS"); 

ownership/OwnershipSystem.java (2 matches)
38: session.executeNonSelectingSQL("Alter TABLE OBJECT_A DROP CONSTRAINT OWNER_A_ONE_TO_ONE_"); 39: session.executeNonSelectingSQL("Alter TABLE OBJECT_C DROP CONSTRAINT OWNER_C_ONE_TO_ONE_");
eclipselink.jpa.test/src/org/eclipse/persistence/testing/models/jpa/advanced/compositepk/CompositePKTableCreator.java (2 matches) 750: session.executeNonSelectingSQL("Alter table CMP3_SCIENTIST drop constraint CMP3_SCIENTIST_CUBICLE"); 751: session.executeNonSelectingSQL("Alter table CMP3_SCIENTIST drop constraint CMP3_SCIENTIST_DEPT"); 

inheritance/InheritanceTableCreator.java
1,674: session.executeNonSelectingSQL("Alter table CMP3_ENGINEER_LAPTOP drop constraint CMP3_ENGINEER_LAPTOP_FK1"); 

xml/advanced/compositepk/CompositePKTableCreator.java (2 matches)
335: session.executeNonSelectingSQL("Alter table CMP3_XML_SCIENTIST drop constraint CMP3_XML_SCIENTIST_CUBICLE"); 336: session.executeNonSelectingSQL("Alter table CMP3_XML_SCIENTIST drop constraint CMP3_XML_SCIENTIST_DEPT");
> Depending on the extent of the issue we will have to either make changes 
 > to the table names throughout the test framework or implement a
 > SessionCustomzier for the tests that fixes the names.  Do you have a
 > list of reserved words that are causing you issues.  With that list,
 > I'll do some searches and see if I can recommend a solution.

I saw issues for:
LANGUAGE
VALUE
DOMAIN
SEQUENCE

I attached a patch of the modification I made to get around SEQUENCE.
5. Java type java.lang.Double maps to SQL type NUMERIC which has a maximum precision of 18 on Symfo. A number of tests try to create tables of this type with a higher precision. - I've changed the tests to obtain the maximum precision from the platform class. Depending on the purpose of the test it might be easier to just reduce the precision to a 'safe' lower value.
For the JPA tests, I suspect we can simply reduce the precision. Do you have a list of tests that are causing you issues? 

No, I picked the issues up from the SQLExceptions in the Ant output.
- If you search the test code for "DOUBLE PRECIS" you'll find it followed by either field.setSize(15) or field.setSize(32). The latter causes the problem.
- If you search the test code for ".setSize(19)" and you find it following "setTypeName("NUMERIC");", it is causing me issues. 

Thanks,
Dies




-Tom
I have some questions regarding other issues I've encountered. I'll prepare an e-mail separately. 

Regards,
Dies
The goal with the JPA tests will be to make the suite run without errors. There are two things we can do to enable that. 

  1. Make the tests pass
2. Determine that the tests are testing features that are not supported by our new database platform, make the tests log warnings, and document the limitation.
Let me know what issues you run into as you get started and I will do my best to help out.
The second set of tests you will be interested in is our foundation tests. These tests are built on a legacy framework (though they are runnable in JUnit) I suggest we worry about those tests after we have dealt with the JPA tests since we will have to do a little more work to determine which of those tests should pass. Let me know when you get to that point, and we can discuss. FYI here is the link to the setup information: 

http://wiki.eclipse.org/EclipseLink/Development/Testing/foundation

Let me know what problems you run into,
-Tom

Dies Koper wrote:

Hi Tom, all,

As I mentioned in my previous e-mail, I'm trying to run the
foundation/eclipselink.core.test JUnit tests on the Symfoware platform. 
Most of them currently fail.
Some are issues with restrictions in Symfoware DB (like you cannot use a reserved keyword as column name (e.g. "LANGUAGE")), a few others I need 
to look at in more detail.
But most are failing because Symfoware DB needs you to create an index 
for tables with a unique constraint. That means that for any
auto-generated table with a PRIMARY KEY, I currently get an error when 
performing a CRUD on the table.

When we created the Symfoware platform class I didn't see this as a
major restriction, I assumed in production systems people would be
creating their own DDL scripts with tuning parameters and indices etc.).
But as the unit tests would be a great base for regression testing for the Symfoware platform, I'm trying to think of a way to get it working 
anyway.
I'd like to explore the possibility of having EclipseLink create the
required indices when creating tables.

So for each create table statement such as the following, I need a
create index statement such as the one below:

CREATE TABLE EJB.CUSTOMER (
             ID          VARCHAR(128)  NOT NULL ,
             NAME        VARCHAR(128)  NOT NULL ,
             AGE         VARCHAR(128) ,
             PRIMARY KEY (ID,NAME)
);

CREATE INDEX EJB.CUSTOMER.IDX1 KEY(ID,NAME);
Is there a particular suitable place in the code where to do this, where I can obtain a list of tables that are to be created (or just after the 
generation of each table DDL) and retrieve which columns have
unique/primary constraints, so I can hook in a platform specific
callback method to insert the index creation DDL for Symfoware so that 
the existing code automatically sends it to the DB and/or file?
Or is there already such a functionality in EclipseLink that I just need 
to enable?

Thanks!
Dies Koper

Back to the top