What is a correct initial value when adding auto icremented primary key?

[Peter Melvyn]

Hi all,

I've updated my Djangro from r7411 to r7519 having changed
OneToOneField implementation which adds autoincremented artificial
primary keys (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY).

I tried update my DB using Django Evolution. It created mutations:

AddField('BIZUserProfile', 'id', models.AutoField, initial=None,
primary_key=True),
ChangeField("BIZUserProfile", "user", initial=None, unique=True,
primary_key=False, db_index=False),

but if applied, it complains with:

Cannot use hinted evolution: AddField ... requires user-specific
initial value

###

What value I should supply as initial value, if field `id` is
autoincremented and it is supposed that no value or NULL will be
supplied.


Thanks, Peter

[Russell Keith-Magee]

On Thu, May 8, 2008 at 3:12 PM, Peter Melvyn <peter....@gmail.com> wrote:
>
> Cannot use hinted evolution: AddField ... requires user-specific
> initial value
>
> ###
>
> What value I should supply as initial value, if field `id` is
> autoincremented and it is supposed that no value or NULL will be
> supplied.

There are two potential bugs here.

One is fairly obvious: An AutoField obviously doesn't require an
initial value, but I don't believe Evolution makes a special case for
fields of that type - it assumes that any non-null field requires an
initial value. I can't think of a workaround - any user-supplied value
will inevitably be wrong. This should be relatively simple to fix, but
please log a ticket so that I don't forget to look at this.

The second potential issue is the change in semantics of
OneToOneField. I haven't looked into this in detail, but I know
Malcolm was talking about making changes to OneToOneFields. If this
means that the same model definition will cause different DB
implementations pre/post the QS-RF merge, we could be in for some fun,
because the current way Evolution is designed is based on the idea
that the relationship between model definition and database definition
is constant. If this is the case, the fix won't be simple, but log a
ticket so I don't forget to look at this.

Yours,
Russ Magee %-)

[Peter Melvyn]

On 5/8/08, Russell Keith-Magee <freakb...@gmail.com> wrote:
> OneToOneField. I haven't looked into this in detail, but I know
> Malcolm was talking about making changes to OneToOneFields.

So am I... I discovered it incidentally while sniffing around MySQL contraints
(and updating Django in the meantime)...

> If this means that the same model definition will cause different DB
> implementations pre/post the QS-RF merge, we could be in for some fun,

Before:

CREATE TABLE `wss_user_profile` (
`user_id` integer NOT NULL PRIMARY KEY,
....
ALTER TABLE `wss_user_profile` ADD CONSTRAINT user_id_refs_id_4eac0a69
FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`);
CREATE INDEX `wss_user_profile_user_id` ON `wss_user_profile` (`user_id`);

After:

CREATE TABLE `wss_user_profile` (
`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
`user_id` integer NOT NULL UNIQUE,
ALTER TABLE `wss_user_profile` ADD CONSTRAINT user_id_refs_id_4eac0a69
FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`);
CREATE UNIQUE INDEX `wss_user_profile_user_id` ON `wss_user_profile`
(`user_id`);

[Peter Melvyn]

On 8 Kvě, 11:19, "Peter Melvyn" <peter.mel...@gmail.com> wrote:

> On 5/8/08, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
>
> >  OneToOneField. I haven't looked into this in detail, but I know
> >  Malcolm was talking about making changes to OneToOneFields.

I read backward incompatibility remarks on QS-RF and artificial PK
can be suppressed by declaring OneToOneField as PK
by setting primary_key=True explicitly.

But it still generates different DDL commands (MySQL):

> Before:
>
> CREATE TABLE `wss_user_profile` (
>     `user_id` integer NOT NULL PRIMARY KEY,
>     ....
> ALTER TABLE `wss_user_profile` ADD CONSTRAINT user_id_refs_id_4eac0a69
> FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`);
> CREATE INDEX `wss_user_profile_user_id` ON `wss_user_profile` (`user_id`);

After:

CREATE TABLE `wss_user_profile` (

`user_id` integer NOT NULL UNIQUE PRIMARY KEY,

....
ALTER TABLE `wss_user_profile` ADD CONSTRAINT
user_id_refs_id_4eac0a69
FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`);

CREATE UNIQUE INDEX `wss_user_profile_user_id` ON `wss_user_profile`
(`user_id`);

###

1. There is reduntant UNIQUE in the column declaration - PK is unique
by the definition
(as it is in the case of all other artificial PKs created by
Django)
2. Both Before/After QS-RF produce a redundant Unique index