UNIQUE in PK declaration of refactored OneToOneField

[Peter Melvyn]

I notices that refactored OneToOneField creates artificial primary key
as UNIQUE, whereas all other primary keys generated by Django omits
such declaration, because it is inherent (at least on MySQL)

Setting kwargs['unique'] = False in OneToOneField constructor
supresses this, but I don know if there are no other dependencies...

Peter

[Karen Tracey]

Is the UNIQUE  causing a problem? 

Karen

[Peter Melvyn]

On 10 Kvě, 18:06, "Karen Tracey" <kmtra...@gmail.com> wrote:

> > Setting kwargs['unique'] = False in OneToOneField constructor
> > supresses this, but I don know if there are no other dependencies...
>
> Is the UNIQUE  causing a problem?

In conjuction with primary key 'per se' probably not. At least MySQL
accepts such syntax in contraty to reference guide:
[UNIQUE [KEY] | [PRIMARY] KEY].

The concern is Django-Evolution, because it seems that DB generated
prior/post 1:1 refactoring is different, more
http://groups.google.com/group/django-evolution/browse_frm/thread/324fc03826fa5064


Peter

[Russell Keith-Magee]

2008/5/11 Peter Melvyn <peter....@gmail.com>:

Peter - while I appreciate your enthusiasm, the issue here is with
Django Evolution, not with Django itself. Django has made a subtle
change to the way a OneToOne field definition is interpreted. This
change makes sense, and is documented as being backwards incompatible.
The fact that this change is inconvenient to Django Evolution is
Django Evolution's problem, not Django's.

Yours,
Russ Magee %-)

[Peter Melvyn]

On 11 Kvě, 11:25, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:

> Django has made a subtle change to the way a OneToOne field definition is interpreted.
> This change makes sense, and is documented as being backwards incompatible.

Yes, I agree and respect it. OTOH, this is no reason to generate SQL
command, which

1. is in contrary to MySQL reference guide
2. introduces inconsistency (one may ask him/herself: why the hell
this PK is declared as UNIQUE whereas all others are not and PKs are
UNIQUE by the definition in 1NF :-?)

> The fact that this change is inconvenient to Django Evolution is
> Django Evolution's problem, not Django's.

I guess there are more inconvenient things in MySQL support like
droping foreign key constraints once created inherently and named by
column's name, other times named by explicit FK creation ;-)

###

From this perspective it seems to me that Django should generate
correct DDL without redundant indeces etc... first


Peter

[Russell Keith-Magee]

2008/5/11 Peter Melvyn <peter....@gmail.com>:

>
> On 11 Kvě, 11:25, "Russell Keith-Magee" <freakboy3...@gmail.com>
> wrote:
>
> > Django has made a subtle change to the way a OneToOne field definition is interpreted.
> > This change makes sense, and is documented as being backwards incompatible.
>
> Yes, I agree and respect it. OTOH, this is no reason to generate SQL
> command, which
>
> 1. is in contrary to MySQL reference guide
> 2. introduces inconsistency (one may ask him/herself: why the hell
> this PK is declared as UNIQUE whereas all others are not and PKs are
> UNIQUE by the definition in 1NF :-?)

No argument here. However, this is unrelated to the issue that Django
Evolution is currently having with the change to OneToOneField.

> From this perspective it seems to me that Django should generate
> correct DDL without redundant indeces etc... first

Again, no argument here. Care to contribute a fix? :-)

Yours,
Russ Magee %-)

[Peter Melvyn]

On 11 Kvě, 15:17, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:

> Again, no argument here. Care to contribute a fix? :-)

At least I'd like, because of working evolutions are our vital
interests...
This is the reason I opened a discussion here, whether it is safe:

- set kwargs['unique'] = False
- set DatabaseFeature.autoindexes_primary_keys = True

It seems it solved the basic discrepancies we've met, so we could try
to live with,
but I'd prefer to have Django experts introspection

Peter