On 2月4日, 下午12时03分, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Tue, 2009-02-03 at 19:47 -0800, Eric Abrahamsen wrote:
>
> > On Feb 4, 11:25 am, Malcolm Tredinnick <malc...@pointy-stick.com>
> > wrote:
> > > On Tue, 2009-02-03 at 19:10 -0800, Eric Abrahamsen wrote:
> > > > Hi there,
>
> > > > I'm unable to do any testing -- my fixtures fail with a "Duplicate
> > > > Entry" error when loading. From what I've googled, this might have
> > > > something to do with a mismatch between my model definitions and the
> > > > sql table definition.
>
> > > "Duplicate Entry" is the database telling you that some column(s) with a
> > > unique constraint are failing the constraint check. So it's
> > > database-level data related and the first thing to check is the data
> > > you're trying to insert.
>
> > Aha! I had assumed duplicate entry meant it thought there were two
> > rows with the same pk. On second thought, that wouldn't make too much
> > sense.
>
> It could very well mean that. A primary key column has a uniqueness
> constraint as part of the requirement (it has to be unique and not-NULL,
> pretty much by definition). In fact, since the only column with a unique
> constraint in the table you give is the primary key column, it almost
> has to be that one that is the problem.
I guess the problem wasn't duplicate pks, but egregious quantities of
otherwise-illegal data, mostly NULL values where empty strings were
required. Even after correcting the bad data (and doing a reset and
reloading it with loaddata, which went without a hitch) I still got
the error whenever I dumped the entire database and loaded it in
testcases as a single fixture. But dumping apps separately, and
loading them only as needed for individual testcases, has cleared
things up. It's left me a little suspicious of my whole setup (can I
get a test framework for my test framework?), but at least it's
working.
Thanks for pushing me in the right direction.
E
>
> > This only helps a little bit, though, since none of the fields have
> > unique=True, none of the db columns are unique, and I've got no
> > unique_together constraints. The fixture is a direct output of
> > dumpdata, in xml format (I get the same error with JSON). The pks are
> > included, but there's no duplication there.
>
> The database would like to disagree with you and I'm inclined to trust
> it.
>
> So either (a) there is a duplicate primary key value, (b) the database
> table is not empty to start with and one of the existing entries clash,
> or (c) you are trying to load that fixture more than once without
> flushing the previous data.
>
> The problem is definitely in the data and/or the number of times it's
> being loaded. So trim things down. For example, what happens if you cut
> it in half? If you reduce it to only a single line? Just the second half
> instead of the first half? What happens if you try to load the data
> manually using "loaddata" into an empty database, instead of using the
> test framework? Et cetera, et cetera.
>
> Regards,
> Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
