triplec1988 / scala-migrations Goto Github PK

Ability to create and drop sequences would be a small convenience.

Extend the test suite to run against different databases.  Properties, such as 
the following could be 
set to override the default use of Derby:
    migrations.test.schema_name
    migrations.test.driver
    migrations.test.jdbc_url
    migrations.test.username
    migrations.test.password

What steps will reproduce the problem?
1. dropColumn("MY_TABLE", "MY_COL") against Oracle.
2. generated SQL of [ALTER TABLE "MY_TABLE" DROP "MY_COL"] generates
"ORA-00905: missing keyword"

What is the expected output? What do you see instead?

Correct SQL for Oracle is one of:

[ALTER TABLE "MY_TABLE" DROP COLUMN "MY_COL"]
[ALTER TABLE "MY_TABLE" DROP ("MY_COL")]

What version of the product are you using? On what operating system?

migrations_2.8.0.Beta1
1.0.0

Please provide any additional information below.

Workaround is to use execute() method directly.

Is smbd interested in mavenizing source codes of scala migrations? I think, it 
may be useful for project. I did it for myself and can post here pom-file and 
changes

Nicholas

There is no support for adding and dropping columns from a table.

It appears that Scala Migrations 2.8.0.beta1 and Scala Library 2.8.0.final 
aren't compatible as the simple migrations discovery fails with method not 
found error.

After initial analysis it looks like Shrinkable interface was changed since the 
time Scala Migrations 2.8.0.beta1 was compiled.

See revision 21285 at 
https://codereview.scala-lang.org/fisheye/browse/scala-svn/scala/trunk/src/libra
ry/scala/collection/generic/Shrinkable.scala

Have each unit test method leave the database in a pristine state so that the 
next unit test runs in 
an empty database.  The current unit tests set up a brand new Derby database 
for each test so there 
is no need to clean up after a test, but if an Oracle or PostgreSQL schema is 
used for testing, then 
the same schema must be reused, so each test should clean up after itself.

One way of doing this is to have each test put a list of table names into a 
private class var that is 
used by the @After method that can drop them all.  JUnit needs to be checked if 
it does run an 
@After method after a test failure.

The test suite required Derby and JUnit but not the whole package, so see if 
those can be split out 
in Ivy.

1. Create amigration
2. Run InstallAllMigrations 
3. Delete migration from FS
4. Re-run InstallAllMigrations

I get the message: The migration version XXX is installed but there is no 
migration class available to back it out.

We use the 1.0.o version.

How is possible to remove a migration? what is the right procedure to follow?

To reproduce the problem:
1. But the Migration classes into a Jar file
2. Store the Jar file under a path with space in the path (e.g. C:\Documents 
and Settings\....) 

The Migratens can't be found in the jar file store under a path with spaces. 
I'm getting this exception:
[error] Test 
fullSurrenderTest(com.efgfp.omega.guaranteedata.GuaranteeDataServiceTest) 
failed: 
C:\Documents%20and%20Settings\chzrhfpbuild\.ivy2\cache\xxx\database-migrator\jar
s\database-migrator-1.0.0.beta.jar (The system cannot find the path specified)
[error]     at java.util.zip.ZipFile.open(Native Method)
[error]     at java.util.zip.ZipFile.<init>(ZipFile.java:114)
[error]     at java.util.jar.JarFile.<init>(JarFile.java:133)
[error]     at java.util.jar.JarFile.<init>(JarFile.java:84)
[error]     at 
com.imageworks.migration.Migrator$.classNamesInJar(Migrator.scala:108)
[error]     at 
com.imageworks.migration.Migrator$.classNamesInResource(Migrator.scala:209)
[error]     at 
com.imageworks.migration.Migrator$.com$imageworks$migration$Migrator$$findMigrat
ions(Migrator.scala:277)
[error]     at 
com.imageworks.migration.Migrator$$anonfun$migrate$1.apply(Migrator.scala:722)
[error]     at 
com.imageworks.migration.Migrator$$anonfun$migrate$1.apply(Migrator.scala:705)
[error]     at 
com.imageworks.migration.Migrator$$anonfun$withLoggingConnection$1.apply(Migrato
r.scala:493)
[error]     at 
com.imageworks.migration.Migrator$$anonfun$withLoggingConnection$1.apply(Migrato
r.scala:492)
[error]     at 
com.imageworks.migration.ConnectionBuilder.withConnection(ConnectionBuilder.scal
a:129)
[error]     at 
com.imageworks.migration.Migrator.withLoggingConnection(Migrator.scala:492)
[error]     at com.imageworks.migration.Migrator.migrate(Migrator.scala:705)

The problem is the %20 in the path to the jar file!

I tracked down the problem to Migrator.classNamesInJar() (line 108). The url is 
encoded and contains "%20" instead of " ".
The problem could be solved by first decoding the path 
(java.net.URLDecoder.decoder()).

I'm using "com.googlecode" % "scala-migrations_2.9.0-1" % "1.0.1"

Thank you for your help!

What steps will reproduce the problem?

1. have a migrations .scala in a certain package
2. have any test .scala file in a package with the same name of the migrations' 
package
3. calling migrator,migrate won't find the migrations .scala file - it tries to 
find the file in the package at the test src, instead of the main src


What is the expected output? What do you see instead?

migrator,migrate should work


What version of the product are you using? On what operating system?

1.0.1-2.8.1 on an ubuntu machine


Please provide any additional information below.

This all is happening when running tests that execute a migrator,migrate, in a 
maven build. For now, I'm avoiding the problem by not having the duplicate 
package naming.

There is no support for dropping a column from an existing table.

According to http://db.apache.org/derby/releases/release-10.7.1.1.cgi, Derby 
1.7 now supports a BOOLEAN data type.

Determine how to handle this.  Should Scala Migrations still always throw an 
UnsupportedColumnTypeException for any Derby database or should it check if 
Derby supports BOOLEAN and use it if it is available?  This could be confusing 
if somebody writes an application on a newer Derby version and then tries to 
run it on an older version.  However, another way to look at it is to treat 
each major database version as a separate database type, in which case it's not 
an issue.  For example, treat the difference between Derby 1.6 and 1.7 the same 
way we treat between Derby and PostgreSQL.

A better way than checking Derby's version number is to use 
DatabaseMetaData.getTypeInfo() which should show that the database supports 
BOOLEAN.  See https://issues.apache.org/jira/browse/DERBY-4730 .

[deleted issue]

It is probably a good idea to add support for vendor specific column types. 
Currently TableDefinition assumes that any column type can be defined by using 
sealed SqlType.

Also it might be a good idea to support custom data types as many databases 
support them.

What version of the product are you using? On what operating system?

1.0.0-2.8.0.final

Please, add DATE and TIME column types support.
Both are part of SQL-92 (http://en.wikipedia.org/wiki/SQL-92).

Current version doesn't have any of two, it only has a TIMESTAMP.

sealed abstract class SqlType

case object BigintType extends SqlType
case object BlobType extends SqlType
case object BooleanType extends SqlType
case object CharType extends SqlType
case object DecimalType extends SqlType
case object IntegerType extends SqlType
case object SmallintType extends SqlType
case object TimestampType extends SqlType
case object VarbinaryType extends SqlType
case object VarcharType extends SqlType

What version of the product are you using? On what operating system?
1.0.0-2.8.0.final

Currently there is no support for renaming a column.

I have a patch for scala-migrations which adds support for H2.  I also modified 
the unit tests to allow them to run against different databases.  Oh yeah, and 
the unit tests pass when run against H2 (except for the grant_and_revoke, which 
was too Derby specific for me to fool with).

My patch can be found in the scala-2.8 branch on 
https://leedm777-h2.googlecode.com/hg/.

See http://www.h2database.com for more information on H2.

--
Initial support for H2.

 * Added H2DatabaseAdapter, and corresponding classes.
 * Added lockTableSql method to DatabaseAdapter, since H2 lacks a
   LOCK TABLE command.* Adapted unit tests so unit test database is configurable.  Currently
   runs with only H2 and Derby.
 * Changed grant_and_revoke test so it only runs on Derby, since the
   migrations have Derby specific code in them.

It would be useful if the migration could just print the SQL it would run 
without actually running it.

Expand Migration with addPrimaryKey and removePrimaryKey methods which would be 
alike addIndex and removeIndex.

Something like:

  def addPrimaryKey(table_name: String,
               column_names: Array[String],
               options: PrimaryKeyOption*): Unit

  def addPrimaryKey(table_name: String,
               column_name: String,
               options: PrimaryKeyOption*): Unit

  def removePrimaryKey(table_name: String, options: PrimaryKeyOption*): Unit

As for options Name should extend PrimaryKeyOption trait the way how it does 
for IndexOption and ForeignKeyOption traits.

Currently there is no support for renaming a table.

In DB2 if table's primary key contains multiple columns it is not possible to 
use PRIMARY KEY modifier in the column's definition but rather one must declare 
a constraint as a part of the CREATE TABLE statement:

CREATE TABLE DUMMY
(
    ID         BIGINT      NOT NULL,
    ID_TYPE    VARCHAR(10) NOT NULL,
    CONSTRAINT PK_DUMMY PRIMARY KEY (ID,ID_TYPE)
)

At present TableDefinition may only contain columns and even more it cannot be 
subclassed to solve the problem as toSql() is declared final.

As per my knowledge similar functionality exists in Oracle database and 
probably other databases.

It would be good to make TableDefinition extendable so that database specific 
extensions may be utilized.

Context:
DB2 9.5 for Linux
scala migrations 1.0.0 for 2.7.7 jdbc3

Add quoteIndexName() to the DatabaseAdapter class and use it instead of 
quoteColumnName() to encode index names within Migration class.

In DB2 when creating index one is expected to specify schema name. Without such 
extension point it isn't possible to create Db2DatabaseAdapter as per my 
understanding.

Context:
DB2 9.5 for Linux
scala migrations 1.0.0 for 2.7.7 jdbc3

Currently there is no support for changing a column to a different type.  This 
may be better being 
left unimplemented and a migration can add a new column with a different name, 
drop the old 
column and then rename the new column to the old column's name.