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 Dies,

  comments inline

Dies Koper wrote:

Hi Tom,

I've been running the JPA test suite on the Symfoware platform.
I'd like to give you a status update.
I have just been able to run the complete suite in one go. Success rate is only 36.61% :( Until now it kept hanging at tests half way (at ResultSet.next of the JDBC driver, called from DatabaseAccessor.basicExecuteCall). I assume a table or row got locked and it's waiting for it to be released. I'm not an expert on Symfoware so I'm disabling those tests for now until I can get a full run. (Most are in JUnitJPQLUnitTestSuite.) 

I'd be glad to help you diagnose this issue when you have more info.



Other issues I have found so far:
1. Symfo does not support addition/removal of unique constraints using ALTER TABLE. It does for CREATE and DROP TABLE. - For now I set supportsUniqueKeyConstraints to false, but it should create the constraints during table CREATE/DROP. - Even with supportsUniqueKeyConstraints to false I see ALTER TABLE DROP CONSTRAINT's in generated DDL files. The path SchemaManager#dropConstraints - TableDefinition#dropConstraintsOnDatabase ... TableDefinition#dropForeignConstraintsOnDatabase checks for supportsForeignKeyConstraints before dropping the constraints, while the path SchemaManager#dropConstraints - TableDefinition#dropConstraintsOnDatabase ... TableDefinition#dropConstraints does not. Shouldn't it do the check too? - Still then, some ALTER TABLE DROP CONSTRAINT's are hard-coded (CompositePKTableCreator#replaceTables).
You are correct. All of the drop constraints methods should check the platform to see whether constraints should be dropped. I cannot see a way that TableDefinition.dropConstraintsOnDatabase will not do the check. In my version, TableDefinition.dropConstraintsOnDatabase calls TableDefinition#dropForeignConstraintsOnDatabase which does the check. What am I missing?
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.
We should be able to fix the hardcoded drop constraint statements fairly easily. Just let me know which classes are causing issues. 



2. As I mentioned, Symfo needs indices on primary and unique keys.
- I have implemented auto-creation/removal of indices on primary keys. I can add it for unique keys when 1. is resolved.
3. Symfo does not allow reserved keywords to be used as table or column names. - I have overridden createPlatformDefaultSequence to use a TableSequence with table name "SEQ_GEN_TABLE". That seems to work although I still see tests trying to create a table with name "SEQUENCE". (by AAA.java for example) 
   - I am renaming the table/column names in the tests for other cases.
4. Symfo does not allow spaces in table/column names, even when using double quotes. 
   - That'll be a limitation for Symfo.
Does Symfo have another Delimiter? (MySQL uses ` by default and some other platforms use other characters) The reason I ask is that I am in the middle of implementing a more flexible way of using delimiters based on the JPA 2.0 requirements. It would allow a delimiter to be specified on SymfowarePlatform. That could potentially solve both the issue with the double quote and the issue with the reserved words.
Otherwise, we'll have to figure out a strategy to make Symfoware work. 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.
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? 

-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



_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

Back to the top