the composite pkey isn't in the model either: there was no way for us to
identify that :P
On Thursday, March 26, 2015 at 8:28:37 PM UTC+1, Ian W. Scott wrote:
>
> Found the problem. There were two rows with the same combination of 'name'
> and 'tag' values. That didn't violate any constraints on
Found the problem. There were two rows with the same combination of 'name'
and 'tag' values. That didn't violate any constraints on the table
definition, so normally there was no difficulty. But it violated the
"unique" constraint on the postgre index that indexed the 'name' and 'tag'
columns t
OK, I ran the test code doing the inserts into a new (empty) table. The
error didn't happen. So there must be some problem with the data in the
existing table and/or index. (From my Googling around it looks like a
matter of the table and index being out of sync? But I'm not sure what that
means
Repairing the table definition didn't help. I'm now going to try the
operations on a fresh table.
On Thursday, March 26, 2015 at 10:42:33 AM UTC-4, Ian W. Scott wrote:
>
> Thanks Niphlod. I hired someone to migrate the db from sqlite to postgre
> and there seem to be some bugs in the migration.
Thanks Niphlod. I hired someone to migrate the db from sqlite to postgre
and there seem to be some bugs in the migration. I hadn't noticed the lack
of reference fields because they were originally there. I think the guy I
hired must have removed them (?!). I'll try repairing the table definition
apart from the repetitive table definition (why reinstating IS_IN_DB when
you can do it simply using 'reference table' instead of db.table ?)
did you try creating the same table from scratch ? i.e. a tag_records2
table, which you can try your things on.
It seems that there is a unique const
6 matches
Mail list logo
