Re: [eclipselink-dev] questions while running JPA JUnit tests

[Tom Ware <tom.ware@xxxxxxxxxx>]

Hi Dies,

  I have started to integrate the patch and I have a couple of questions/comments:

- EmployeeSystem - why are we removing the call to dropTableConstraints()?
- There are a number of places where a DeleteAll query has been replaces by a 
native query.  (e.g. EntityMappingsAdvancedTestSuite, 
EntityManagerTLRJUnitTestSuite, EntityManagerJunitTestSuite)  I am concerned 
that this does not account for the multi-table nature of Employee.  I am also 
concerned that adding more native statements will not adapt if the model changes 
either to remove the multi-table nature, or to add another table)  Perhaps we 
should isolate these calls to the case where Symfoware is active.

-Tom

Dies Koper wrote:
> Hi Tom,
>
> I'm getting the same! Sorry about that.
>
> I've prepared the patch again, confirmed there is no error when applying 
> it, and uploaded it again.
>
> Thanks,
> Dies
>
>
> On 27/01/2010 05:55, Tom Ware wrote:
> > Hi Dies,
> >
> > Can you try to reupload? I am getting an error that says: "An unknown
> > line type was found in line 1380" when I try to apply the patch.
> >
> > -Tom
> >
> > Dies Koper wrote:
> > > Hi Tom,
> > >
> > > I have attached the patch with the complete set of changes.
> > > Please let me know if you have any questions.
> > >
> > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=288715
> > >
> > > Thanks,
> > > Dies
> > >
> > >
> > > On 26/01/2010 02:06, Tom Ware wrote:
> > > > Hi Dies,
> > > >
> > > > Is it possible to provide a single patch with your complete change set
> > > > based on the latest code? If you can provide that, I'll start working
> > > > integrating and testing the changes.
> > > >
> > > > -Tom
> > > >
> > > > Dies Koper wrote:
> > > > > Hi Tom, James,
> > > > >
> > > > > I ended up implementing this after all.
> > > > > Patch (completely split settings) attached to the Symfoware issue.
> > > > >
> > > > > The reason is that Symfoware ignores the setMaxRows setting depending
> > > > > on the cursor type, causing some tests to fail. At least with LIMIT I
> > > > > can be sure that it works no matter what the cursor policy is.
> > > > >
> > > > > With this patch, Andrei's (for SCHEMA table name) and the previous one
> > > > > I uploaded, I have completed all changes to common code that I need
> > > > > for Symfoware to work.
> > > > > With these I passed 100% of the SRG test sets, and Core LRG.
> > > > > Please let me know when you can accept the final patch with the
> > > > > Symfoware platform class itself, the isSymfoware() methods and the
> > > > > inclusions/exclusions to the tests for Symfoware.
> > > > >
> > > > > Thanks,
> > > > > Dies
> > > > >
> > > > >
> > > > > On 16/12/2009 01:51, Tom Ware wrote:
> > > > > > Hi Dies,
> > > > > >
> > > > > > To check this in, the setting will have to be completely split. i.e.
> > > > > > remove the methods that affect both settings
> > > > > > (setIgnoreFirstResultsMaxRowsSettings and
> > > > > > shouldIgnoreFirstResultsMaxRowsSettings). Instead, have separate
> > > > > > getters
> > > > > > and setters for each setting, and make the appropriate changes to
> > > > > > classes depending on those methods.
> > > > > >
> > > > > > -Tom
> > > > > >
> > > > > > Dies Koper wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > > I have started looking at your patch. I have a quick question:
> > > > > > > >
> > > > > > > > - In DatabaseAccessor, what is the goal of splitting the
> > > > > > > > ignoreFirstRowSettings and the ignoreMaxResultsSettings
> > > > > > >
> > > > > > > Symfoware supports LIMIT, but has no equivalent for OFFSET.
> > > > > > >
> > > > > > > Currently, the flag setIgnoreFirstRowMaxResultsSettings toggles 
> > > > > > > both,
> > > > > > > so either both JDBC absolute and setMaxRows are called, or both are
> > > > > > > not.
> > > > > > >
> > > > > > > To support pagination using SQL I override printSQLSelectStatement
> > > > > > > like the other platforms do, but as I only have a LIMIT in the
> > > > > > > query I
> > > > > > > need EclipseLink to only call the JDBC absolute method when FirstRow
> > > > > > > is set.
> > > > > > >
> > > > > > > So my implementation method looks like:
> > > > > > >
> > > > > > > public void printSQLSelectStatement(DatabaseCall call,
> > > > > > > ExpressionSQLPrinter printer, SQLSelectStatement statement) {
> > > > > > > int max = 0;
> > > > > > > int firstRow = 0;
> > > > > > >
> > > > > > > statement.setMaximumAliasLength(getMaxFieldNameSize());
> > > > > > > if (statement.getQuery() != null) {
> > > > > > > max = statement.getQuery().getMaxRows();
> > > > > > > firstRow = statement.getQuery().getFirstResult();
> > > > > > > }
> > > > > > >
> > > > > > > // only MaxRows can be worked into the statement
> > > > > > > if (max > 0 && this.shouldUseRownumFiltering()) {
> > > > > > > statement.setUseUniqueFieldAliases(true);
> > > > > > > call.setFields(statement.printSQL(printer));
> > > > > > > printer.printString(" WITH OPTION LIMIT (");
> > > > > > > printer.printParameter(DatabaseCall.MAXROW_FIELD);
> > > > > > > printer.printString(")");
> > > > > > >
> > > > > > > call.setIgnoreMaxResultsSettings(true);
> > > > > > > } else {
> > > > > > > // use JDBC absolute and setMaxRows methods for pagination
> > > > > > > super.printSQLSelectStatement(call, printer, statement);
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Dies
> > > > > > >
> > > > > > >
> > > > > > > > Dies Koper wrote:
> > > > > > > > > Hi Tom, all
> > > > > > > > >
> > > > > > > > > Congrats on the 2.0 release!
> > > > > > > > >
> > > > > > > > > I've been continuing running the test sets on the Symfoware
> > > > > > > > > platform.
> > > > > > > > > May I ask you for you help with the following three issues?
> > > > > > > > >
> > > > > > > > > 1. Review of patch
> > > > > > > > >
> > > > > > > > > I've added a patch with changes required for a number of tests to
> > > > > > > > > run. Could you review them, and if okay, commit them?
> > > > > > > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=288715
> > > > > > > > >
> > > > > > > > > 2. Where is table name "SEQUENCE" defined?
> > > > > > > > >
> > > > > > > > > I tried renaming all occurrences of the word "SEQUENCE" in the 
> > > > > > > > > code
> > > > > > > > > I could find but still some tests try to create a sequence table
> > > > > > > > > with table name SEQUENCE.
> > > > > > > > > It starts with the 8th test in the JPA test set:
> > > > > > > > > testTransitionToDeferedFailure
> > > > > > > > >
> > > > > > > > > which tries a UPDATE SEQUENCE (...).
> > > > > > > > >
> > > > > > > > > In the log I see even more:
> > > > > > > > >
> > > > > > > > > [junit] [EL Config]:
> > > > > > > > > ServerSession(1006920425)--Thread(Thread[main,5,main])--The table
> > > > > > > > > generator name defined within [class
> > > > > > > > > org.eclipse.persistence.testing.models.jpa.inherited.Alpine] is
> > > > > > > > > being defaulted to: SEQUENCE.
> > > > > > > > >
> > > > > > > > > and
> > > > > > > > >
> > > > > > > > > [junit] [EL Fine]:
> > > > > > > > > ServerSession(1006920425)--Connection(753758527)--Thread(Thread[main,5,main])--CREATE 
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT
> > > > > > > > > DECIMAL(18), PRIMARY KEY (SEQ_NAME))
> > > > > > > > > [junit] java.sql.SQLException: [SymfoWARE ODBC Driver][SymfoWARE
> > > > > > > > > [...]
> > > > > > > > > [junit] at
> > > > > > > > > org.eclipse.persistence.testing.tests.jpa.advanced.concurrency.LifecycleJUnitTest.testSetup(LifecycleJUnitTest.java:76) 
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I believe these might be from the CONCURRENCYA, B and C tables, or
> > > > > > > > > ConcurrencyA, B and C entities. Each of them has
> > > > > > > > > fieldID.setIsIdentity(true) resp. @GeneratedValue specified but 
> > > > > > > > > the
> > > > > > > > > details of the sequence generators are omitted.
> > > > > > > > >
> > > > > > > > > I though it would default to what the platform's
> > > > > > > > > createPlatformDefaultSequence() method returns but apparently not.
> > > > > > > > >
> > > > > > > > > Many tests fail because of this issue.
> > > > > > > > >
> > > > > > > > > 3. Table locks during DROP TABLE
> > > > > > > > >
> > > > > > > > > In the SymfowarePlatform wiki page you suggested that we should
> > > > > > > > > start by trying to get the Core SRG running first. Most are 
> > > > > > > > > passing
> > > > > > > > > now.
> > > > > > > > >
> > > > > > > > > Only a few (the ReadAllTest tests, which rely on
> > > > > > > > > AutoTableGeneratorBasicTestModel.java) failed I think because of
> > > > > > > > > the
> > > > > > > > > table lock issue.
> > > > > > > > >
> > > > > > > > > The error message is:
> > > > > > > > >
> > > > > > > > > Exception Description: 24 objects were read from the database, but
> > > > > > > > > originially there were, 12.
> > > > > > > > >
> > > > > > > > > When I run it by itself through the test browser it passes without
> > > > > > > > > problems.
> > > > > > > > >
> > > > > > > > > Some messages in the finest log let me believe this is because a
> > > > > > > > > problem
> > > > > > > > > occurred while recreating the tables: they should have been
> > > > > > > > > dropped and
> > > > > > > > > recreated, thereby clearing those old 12 object, but because of 
> > > > > > > > > the
> > > > > > > > > locking issue they were not.
> > > > > > > > >
> > > > > > > > > [junit] Internal Exception: java.sql.SQLException: [SymfoWARE ODBC
> > > > > > > > > Driver][SymfoWARE Server] JYP3913E : Table "PHONE" being used
> > > > > > > > > exclusively by another user.
> > > > > > > > > [junit] Error Code: -3913
> > > > > > > > > [junit] Call: drop table PHONE
> > > > > > > > > [junit] Query: DataModifyQuery(sql="drop table PHONE")
> > > > > > > > > [junit] at
> > > > > > > > > org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:324) 
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > [..]
> > > > > > > > > [junit] at
> > > > > > > > > org.eclipse.persistence.testing.models.employee.relational.EmployeeSystem.dropTableConstraints(EmployeeSystem.java:86) 
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > [junit] at
> > > > > > > > > org.eclipse.persistence.testing.tests.schemaframework.AutoTableGeneratorEmployeeSystem.createTables(AutoTableGeneratorEmployeeSystem.java:32) 
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > This table was created and accessed as follows:
> > > > > > > > >
> > > > > > > > > 1. drop (index) and table (outside transaction)
> > > > > > > > > DROP TABLE PHONE
> > > > > > > > >
> > > > > > > > > 2. create table (and index) (in transaction), same connection
> > > > > > > > > CREATE TABLE PHONE (EMP_ID NUMERIC(15) NOT NULL, TYPE VARCHAR(15)
> > > > > > > > > NOT NULL, AREA_CODE VARCHAR(3), P_NUMBER VARCHAR(7), PRIMARY KEY
> > > > > > > > > (EMP_ID, TYPE))
> > > > > > > > >
> > > > > > > > > 3. insert 30 rows (in single transaction), same connection
> > > > > > > > > INSERT INTO PHONE (TYPE, AREA_CODE, P_NUMBER, EMP_ID) VALUES 
> > > > > > > > > (?, ?,
> > > > > > > > > ?, ?)
> > > > > > > > > [junit] bind => [Home, 613, 5551234, 105]
> > > > > > > > >
> > > > > > > > > 4. drop (index) and table (outside transaction), different
> > > > > > > > > connection
> > > > > > > > > DROP TABLE PHONE
> > > > > > > > > -> SQLException saying PHONE is locked.
> > > > > > > > >
> > > > > > > > > I can reproduce this in a simple JDBC application. If I close the
> > > > > > > > > connection used in steps 1-3 before step 4 it works fine.
> > > > > > > > >
> > > > > > > > > I can see some session swapping is done in
> > > > > > > > > AutoTableGeneratorBasicTestModel#addForcedRequiredSystems() so I
> > > > > > > > > tried adding a reset() invocation at the start of its
> > > > > > > > > addForcedRequiredSystems() method but that did not help.
> > > > > > > > > How can I make it close the physical connection?
> > > > > > > > > (You mentioned adding logic into TestSystem?)
> > > > > > > > >
> > > > > > > > > The lock issue occurs much more often in the JPA test set. The
> > > > > > > > > first
> > > > > > > > > failing test however is because of the reserved SEQUENCE keyword
> > > > > > > > > used as table name, so if you could help me in the right direction
> > > > > > > > > with the above three issues I can try move forward with this test
> > > > > > > > > set again.
> > > > > > > > >
> > > > > > > > > Thanks!
> > > > > > > > > Dies
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Tom Ware wrote:
> > > > > > > > > > Hi Dies,
> > > > > > > > > >
> > > > > > > > > > FYI: I am working on integrating your initial patch. There are a
> > > > > > > > > > couple of items I will not be integrating at the moment:
> > > > > > > > > >
> > > > > > > > > > 1. Specific references to SymfowarePlatform and
> > > > > > > > > > isSymfowarePlatform(). These will be left until SymfowarePlatform
> > > > > > > > > > becomes part of the full product
> > > > > > > > > >
> > > > > > > > > > 2. Changes to default SEQUENCE table name to "\"SEQUENCE\"" for
> > > > > > > > > > our
> > > > > > > > > > Sessions and project XML (in XMLSessionConfigProject,
> > > > > > > > > > ObjectPersistenceRuntimeXMLProject and SequencingConfig). This is
> > > > > > > > > > simply to big a backward compatibility risk since I cannot test
> > > > > > > > > > these changes on every database platform that EclipseLink is
> > > > > > > > > > run on
> > > > > > > > > > by our customers. I am looking for some way of having this
> > > > > > > > > > information stored on the DatabasePlatform, but at the moment, it
> > > > > > > > > > is not looking good. Assuming I do not find a good solution,
> > > > > > > > > > Symfoware users will simply have to explicitly set these items
> > > > > > > > > > when
> > > > > > > > > > using our proprietary configuration code (sessions.xml and
> > > > > > > > > > deployment.xml) We will also have to address anywhere in the 
> > > > > > > > > > tests
> > > > > > > > > > we choose to run where this is an issue.
> > > > > > > > > >
> > > > > > > > > > I am in the process of running testing on the other changes and
> > > > > > > > > > I'll let you know when it gets checked in.
> > > > > > > > > >
> > > > > > > > > > -Tom
> > > > > > > > > >
> > > > > > > > > > Dies Koper wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > I have added the outstanding issues with SQL keywords in
> > > > > > > > > > > table/columns names, and maximum precision. The biggest open
> > > > > > > > > > > issue
> > > > > > > > > > > is of course the drop table restriction. I'm looking forward to
> > > > > > > > > > > hearing what solution(s) you can come up with.
> > > > > > > > > > >
> > > > > > > > > > > Thanks!
> > > > > > > > > > > Dies
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Tom Ware wrote:
> > > > > > > > > > > > Hi Dies,
> > > > > > > > > > > >
> > > > > > > > > > > > I am moving some of the main points of this discussion to the
> > > > > > > > > > > > wiki page so I can more easily keep track of where we are:
> > > > > > > > > > > >
> > > > > > > > > > > > http://wiki.eclipse.org/EclipseLink/Development/Incubator/Extensions/SymfowarePlatform#Open_Issues 
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I started by just adding some basics about the main issues that
> > > > > > > > > > > > are getting in the way at the moment. I plan to add more detail
> > > > > > > > > > > > next week. Please feel free to add other issues I have
> > > > > > > > > > > > missed, or
> > > > > > > > > > > > more detail.
> > > > > > > > > > > >
> > > > > > > > > > > > As for some of the other things you were wondering about:
> > > > > > > > > > > >
> > > > > > > > > > > > 1. Your initial patch (including sequencing fixes etc.). I hope
> > > > > > > > > > > > to find some time to start integrating it next week
> > > > > > > > > > > >
> > > > > > > > > > > > 2. EclipseLink bug 286907 (not related to Symfoware platform)-
> > > > > > > > > > > > this bug is in the queue and will be addressed in sequence with
> > > > > > > > > > > > the other bugs. The fact that you have submitted a patch
> > > > > > > > > > > > means it
> > > > > > > > > > > > will potentially jump other bugs in the queue. At the moment
> > > > > > > > > > > > I am
> > > > > > > > > > > > going to focus on the Symfoware Platform issues with my free
> > > > > > > > > > > > time, so I can't make any promises about when it will be
> > > > > > > > > > > > included.
> > > > > > > > > > > >
> > > > > > > > > > > > 3. GlassFish bug 9179 (not related to Symfoware platform) - 
> > > > > > > > > > > > same
> > > > > > > > > > > > thing as above, but additionally: we cannot legally make use of
> > > > > > > > > > > > the submitted patch until it is attached to EclipseLink bug by
> > > > > > > > > > > > someone with IP rights
> > > > > > > > > > > >
> > > > > > > > > > > > I'll get started looking for some solutions next week.
> > > > > > > > > > > > -Tom
>
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev