Empty error message when executing raw SQL evolution

[Russ]

Hi,

I'm new to evolution, so apologies if the problem here is something
that I have caused.

I have added a foreign key field to a table that already contains
data, which as far as I can tell requires a raw XML mutation.

I have added an 'evolution' package to the application and added a
add_user.sql file which contains the following:

ALTER TABLE "application_model" ADD COLUMN "user_id" integer NULL
REFERENCES "auth_user" ("id") DEFERRABLE INITIALLY DEFERRED;
CREATE INDEX "application_model_user_id" ON
"application_model" ("user_id");
UPDATE "application_model" SET "user_id"=(SELECT "id" FROM "auth_user"
WHERE username='me');
ALTER TABLE "application_model" ALTER COLUMN "user_id" SET NOT NULL;

(Table name changed to something generic).

I have run these four steps in a transaction and they apply fine: the
field gets added with foreign key, UPDATEd, an index added and the NOT
NULL constraint added.

evolve --sql shows that it is picking this custom SQL up.

The problem is that when I actually come to run it, I get this output:

Are you sure you want to execute the evolutions?

Type 'yes' to continue, or 'no' to cancel: yes
Error applying evolution:

And nothing else. No error message. Increasing verbosity seems to make
no difference, and neither did --traceback. I found one mention of a
problem like this which mentioned the last semicolon being a problem,
but removing it had no effect, so I'm at a bit of a loss at this
point.

I am running django 1.0.2 and django-evolution 0+svn164-1 (Ubuntu
package). Any help would be appreciated.

Thanks.

--

Russ.

[Russell Keith-Magee]

On Sun, May 17, 2009 at 12:19 PM, Russ <picks...@gmail.com> wrote:
>
> I have run these four steps in a transaction and they apply fine: the
> field gets added with foreign key, UPDATEd, an index added and the NOT
> NULL constraint added.
>
> evolve --sql shows that it is picking this custom SQL up.
>
> The problem is that when I actually come to run it, I get this output:
>
> Are you sure you want to execute the evolutions?
>
> Type 'yes' to continue, or 'no' to cancel: yes
> Error applying evolution:
>
> And nothing else. No error message. Increasing verbosity seems to make
> no difference, and neither did --traceback. I found one mention of a
> problem like this which mentioned the last semicolon being a problem,
> but removing it had no effect, so I'm at a bit of a loss at this
> point.

I'm afraid I am at a bit of a loss here, too. This error (or lack
thereof) doesn't make much sense to me - I can't think of any reason
you would be seeing the behaviour you are seeing. The code in question
here is lines 208-210 of
django_evolution/management/commands/evolve.py:

except Exception, ex:
transaction.rollback()
print self.style.ERROR('Error applying
evolution: %s' % str(ex))

If you're seeing nothing after the "Error applying evolution" step,
then it means that whatever exception is being raised, it can't be
printed - either because the __str__ method is deliberately empty, or
printing the error is itself raising an error.

All I can suggest here is that you put some extra debug code into this
exception block, and try and find out anything you can about the
exception that is being raised - the class of exception, and
attributes of the exception, etc. As an end, this will hopefully show
you what is going wrong in your evolution; more generally, it may
provide some suggestions as to what needs to be improved in the way
Evolution outputs error messages in this case.

Yours,
Russ Magee %-)

[Russ Brown]

On May 17, 6:19 am, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:

Thanks for the pointers Russ, I'll do some digging later and report
back my findings here.

--

Russ (Brown)

[Russ Brown]

On May 17, 6:19 am, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:

Hi,

I have now figured out what the problem was. It was an empty line at
the end of my SQL file.

I determined that the exception being thrown was ProgrammingError,
which I figured came from psycopg2. In the psycopg2 changelog I found
a note that it would raise that if the query was empty, and noted that
my file did have an empty line at the end. Removing it allowed the
operation to complete successfully.

It looks like this is already covered by issue 30. However, that issue
seems to cover a much larger problem, while from what I can tell my
problem could be solved pretty easily by just checking for an empty
(or whitespace only) string before running each query.

Thanks again for your help,

Russ Brown.

[Russell Keith-Magee]

On Tue, May 19, 2009 at 5:33 AM, Russ Brown <picks...@gmail.com> wrote:
>
> I have now figured out what the problem was. It was an empty line at
> the end of my SQL file.
>
> I determined that the exception being thrown was ProgrammingError,
> which I figured came from psycopg2. In the psycopg2 changelog I found
> a note that it would raise that if the query was empty, and noted that
> my file did have an empty line at the end. Removing it allowed the
> operation to complete successfully.
>
> It looks like this is already covered by issue 30. However, that issue
> seems to cover a much larger problem, while from what I can tell my
> problem could be solved pretty easily by just checking for an empty
> (or whitespace only) string before running each query.

Excellent! Thanks for the debug work here, Russ. A full and complete
solution for #30 will be complex, but as you say, the simple case of
checking for an empty string should be a relatively simple improvment.
I don't know when I'll get a chance to look at this, but I'll put it
on the list :-)

Yours
Russ Magee %-)