Getting SQL Server running (issues with threads, transactions, and #2358)
Moof
Server 2005 Express, and it fails abysmally.
I discovered patch #2358. Elsewhere on the list, people claim it
works, but using the latest SVN head, it doesn't even manage to run
the test suite.
I decided to give it a bit of a go, and I've made some progress, but
I'm now well out of my depth, and I'd appreciate some categorical
answers from people on the list, in an attempt to track down the place
where the bug is happening.
My latest bugbear is the following: on running the test suite, and
attempting to load the first fixture, it tries to create
comment_karmascore before comment_comment, despite the fact that
comment_comment creation command was issued before the
comment_karmascore creation command. Test suite output is available
here:
http://code.djangoproject.com/attachment/ticket/2358/patch_9_test_output.txt
Inspecting the database after running shows me that none of the
"comment" databases are created, though the rest of the databases have
been created.
So, now I need help understanding the core django design:
1. Is test database creation at all multithreaded? If so, why?
2. During database creation, are the tables for each app created
within one transaction? Or one per table?
3. Has anyone else had similar issues using other database backends?
4. Any other ideas as to what else I can look at?
I hope that you guys can help me with this issue, it'd be good to get
MS SQL Server support running.
Moof
Moof
On Mar 20, 6:29 pm, "Moof" <m...@metamoof.net> wrote:
> Well, I decided to try getting django running on my box, with SQL
> Server 2005 Express, and it fails abysmally.
<snip>
OK, so I can't read ado_mssql errors correctly. It's not the lack of
comments_comment that's the issue, it's the foreign key creation.
Specifically:
"Introducing FOREIGN KEY constraint 'FK__comments___comme__3B75D760'
on table 'comments_karmascore' may cause cycles or multiple cascade
paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify
other FOREIGN KEY constraints."
OK. This *is* my fault, but again, I'm unsure how to continue.
I have the following problem:
On attempting to flush a small test database, I came across the
problem that deleting certain rows would fail due to the fact that, by
default, deletes do not cascade on MSSQL, and it was attempting to
delete in the wrong order. So I added the ON DELETE CASCADE keyword to
all table creation, which could well be stupid.
Anyway, for the moment, I've removed it, I'll keep fixing until I come
across this issue again, and ask how to deal with it then.
Sorry for the bother *^_^*
Moof