on Sun, 1 Mar 2009 11:34 -0800 (PST) NewSpire wrote:
> I'll note that if the AutoField is defined with unique=True the table create
> works.
but On Mar 3, 6:19 pm, NewSpire wrote:
>
> Crazy Gul, ;-) the order of the records, in my case, is only
> important in the context of a foreign in key.
> Django is optimized for the common case. Sure, it may well be that
> it's easy to accommodate uncommon cases as well, and when it's
> reasonable, we should definitely do so, but the reason it hasn't been
> up to this point is simply that not enough people need it.
I agree fully. I've only need
On Sun, Mar 1, 2009 at 8:25 AM, NewSpire wrote:
>
>> MySQL, if I recall correctly,
>> flat-out will not support this at all.
>
> Correct! MySQL definitely does not support multiple auto-increment
> fields. However, that is not what I'm talking about. I would just
> like the primary key require
On Sat, Feb 28, 2009 at 11:27 PM, NewSpire wrote:
> First, this restriction is not there in the database. Auto-increment
> fields do not have to be primary keys. Imposing this restriction
> could cause a problem when trying to use legacy tables in a Django
> environment. Is there a compelling
Now for some leg work.
The simple part is to remove the primary key assert in
AutoField.__init__.
The hard part is that django creates tables with multiple sql
statements. One for the table create and then one for each index.
MySQL requires that auto_increment fields must be indexed. Since
dja
> my records are created in several satellite systems
Ah, that is, the legacy database is involved. It makes the example
even more vivid - having a legacy primary key while still having the
convenience of a non-primary autofield.
I fully agree that we better should NOT add any backend-dependent
> MySQL, if I recall correctly,
> flat-out will not support this at all.
Correct! MySQL definitely does not support multiple auto-increment
fields. However, that is not what I'm talking about. I would just
like the primary key requirement removed from the AutoField. MySQL
definitely does not
On Sun, Mar 1, 2009 at 7:41 AM, Alex Myodov wrote:
>
> Well, according to "If there's some really strong use-case that's been
> overlooked here, it can be brought up in a thread on django-dev", I
> think I need to explain the feature a bit better.
>
> Why we may ever need to have autofields being
Well, according to "If there's some really strong use-case that's been
overlooked here, it can be brought up in a thread on django-dev", I
think I need to explain the feature a bit better.
Why we may ever need to have autofields being non-primary-keys?
To be able to use several autofields in a si
As a person that raised the problem initially, I can only add several
words to the current discussion thread on the issue: kmtracey
mentioned that "as I can find no mention of AutoField on the
referenced IRC page, so I'll just put it back to DDN", so, in fact my
explanation of the use case is pres
In ticket #8576 a request was made to remove the restriction that
AutoFields must be primary keys so that multiple AutoFields could be
used in a model. In MySQL multiple auto-increment fields does not
make sense and probably does not make sense in any other database.
However, I do think the case
11 matches
Mail list logo
