Diffa Diffa → 1.0

Comments and changes to this ticket

• 

  Ben Hood November 1st, 2011 @ 02:40 PM

  • Milestone set to “1.0”
  • Milestone order changed from “135” to “0”
• 

  Paul Jones November 8th, 2011 @ 12:48 AM

  • Milestone order changed from “4” to “0”

  There isn't any chance that the migration could have previous half run against the database? I can't see what is special about that create table versus any of the previous that have been run.

• 

  Ben Hood November 8th, 2011 @ 06:56 AM

  Potentially - I think it maybe a case of running the HibernatePreparationTest against an Oracle dev schema, which is what I'd like to do before I close #399 (although it has been merged already, since it fixes something already).

• 

  Paul Jones November 8th, 2011 @ 07:19 AM

  Running that test against Oracle (or many DBs in fact) might be a little fiddly since the .sql files that generate the various states are probably quite HSQLDB/Derby specific.

• You flagged this item as spam.
  

  John Wright November 8th, 2011 @ 05:20 PM

  Here's a (fiddly) way to reproduce this issue:

  To initialize a clean Oracle database to schema version 8:

  1. Check out and build from commit 0be5974bbf67bd271aca6d6607410a2cd1326832
     
  2. Comment out all @DataPoint definitions except for "emptyDb" in HibernatePreparationTest.scala
     
  3. Add a test-scoped dependency on the Oracle driver in kernel/pom.xml
     

  4. Run the HibernatePreparationTest with the following system properties set:

     mvn test -Dtest=HibernatePreparationTest -DforkMode=never -Ddiffa.hibernate.dialect=org.hibernate.dialect.Oracle10gDialect -Ddiffa.jdbc.driver=oracle.jdbc.driver.OracleDriver -Ddiffa.jdbc.url=[oracle jdbc url] -Ddiffa.jdbc.username=[oracle username] -Ddiffa.jdbc.password=[oracle password]

  Then, to recreate the migration from schema version 8 to 9:

  1. Check out and build from commit 43cfcd7ff9d7690275ba03dff045912261e51560
     

  2. Comment out all @DataPoint definitions in HibernatePreparationTest.scala and add the following new one:

     @DataPoint def v8 = StartingDatabaseVersion("v8")

  3. Comment out the entire block of code after the "Prepare the starting database" comment in the shouldBeAbleToPrepareDatabaseVersion method of HibernatePreparationTest. The block starts like this: "sf.withSessions(s => {"
     

  4. Add a test-scoped dependency on the Oracle driver in kernel/pom.xml as before
     
  5. Run the HibernatePreparationTest as before

• You flagged this item as spam.
  

  John Wright November 8th, 2011 @ 05:33 PM

  It turns out that issue is caused by a bug in CreateTableBuilder. The store_checkpoints table has a multi-column primary key, but the current logic assumes that since the Oracle dialect doesn't support identity columns then sequences must be created. Consequently, it attempts to create a sequence called "domain" after the first column in the primary key, which results in the "name is already used by an existing object" error.

  A possible fix for this would be to change the condition on CreateTableBuilder#apply from:

  if (!dialect.supportsIdentityColumns()) {
  

  to:

  if (identityCol && ! dialect.supportsIdentityColumns()) {
  

  However, this does not address an edge case in which a table's primary key consists of multiple columns, but one (or more) of them requires a corresponding sequence to be created.

• You flagged this item as spam.
  

  John Wright November 8th, 2011 @ 05:53 PM

  In need of pre-QA sanity check:

  https://github.com/lshift/diffa/pull/106

• 

  Paul Jones November 8th, 2011 @ 10:10 PM

  • Assigned user set to “Paul Jones”
  • State changed from “new” to “open”

  I'll take a look at this.

• 

  Ben Hood November 8th, 2011 @ 10:21 PM

  • Assigned user changed from “Paul Jones” to “Ben Hood”
  • State changed from “open” to “resolved”

  On the whole, this patch looks good - I'll deploy this against Oracle, and if that goes well, I'll close this ticket.

• 

  Paul Jones November 8th, 2011 @ 10:25 PM

  It probably isn't in the scope of this ticket, but I think we should revise the way that we define sequences. Given that Hibernate supports specifying sequence names for individual columns, we should consider doing the same instead of just basing it on the column name - since wouldn't we see this error appear any time a set of tables had columns called "id" or similar?

• 

  Ben Hood November 9th, 2011 @ 05:42 AM

  • State changed from “resolved” to “closed”

  • I've tested a fresh migration against a dev instance of Oracle and it was able to migrate from scratch to version 14.
  • Raised #412 to cover the follow up.

  -> QA+