That's not a bad idea, Paul. Thanks for the tip.
My solution ended up being somewhat hacked, but it works. In addition
to our usual "development" databases, we will add a "test" database that
can be trashed by these functional unit tests. So, from our functional
test base class we drop and r
I would love to say one day the portability issues between databases would be
fixed, but well I only see yet more divergence in the future. None of the
database designers care much about the SQL standards, which means that without
DBMS specific setups only the simplest of databases can work wit
I figured out the problem.
HypersonicSQL does not keep indexes as subordinates to their
corresponding tables. In our changelog.xml, we have indexes associated
with multiple tables for which the index has the same name. (ie. K_code
is an index name on tables A, B, and C). This works fine in m
Nevermind, I misread the XML...
On Mar 11, 2009, at 12:58 PM, Peter Rebholz wrote:
> I'm not very familiar with HSQL or MySQL but is it possible that
> it's complaining because the primary key (product_type) is indexed
> by default? Oracle behaves this way.
>
>
> On Mar 11, 2009, at 12:43 PM,
I'm not very familiar with HSQL or MySQL but is it possible that it's
complaining because the primary key (product_type) is indexed by
default? Oracle behaves this way.
On Mar 11, 2009, at 12:43 PM, David C. Hicks wrote:
> A little more info/revision:
>
> I see now that the entire changelog.
A little more info/revision:
I see now that the entire changelog.xml is *not* being performed. It
does, indeed, bail out on the first failure. I just don't understand
why, I guess. Here is the specific change set that is failing:
Hi guys,
I've been trying to get Liquibase to run our changelog.xml using the
API. I found a piece of code that Nathan had made available to someone
at a previous time. It seems to work, mostly, but I get a SQLException
at the end of it all. Here's a code excerpt:
private void doLiquib
