[
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