Not being a part of the developers, but being interested in the proper
resolution of this feature, I just second this request: somewhen this
just should be dealt with.
My own understanding is that lacking a stock BigInt field (or some
stock customization capability of the Integer field that would
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
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
> 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
Sorry for the shameless messing in, but... if you want a release to be
considered rock-stable and proven from the beginning,.. never name it
2.0. Neither 1.0. Nor any *.0.
"Anything-dot-zero" obviously stands for "just released after a rush
to fit into the deadline" and implies "let's wait for oth
Hi all.
Can someone experienced please have a look at the #3163 ticket
("sql_generation_required" Meta option) and hint me what other steps
should I do to move the patch forward? I have a suspicion that the
testcases are the only remaining thing - but then, can someone hint me
how these testcases
James, the answer is - "cause these people may still want to run
"manage.py syncdb" for other models in the same app". You use
"manage.py syncdb/reset/something" for the whole application (cause
you are still doing the development, and the table structure changes
from day to day), and all the tabl
work (according to some other testcases).
On 13 дек, 02:10, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-12-12 at 05:29 -0800, Alex Myodov wrote:
> > Hi all.
>
> > Can someone experienced please have a look at the #3163 ticket
> > ("sql_generation
another can of worms :) )
On 13 дек, 10:19, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-12-12 at 23:15 -0800, Alex Myodov wrote:
> > Thanks for ideas, Malcolm.
> > I am slightly against "create_db_table", cause the name implies that
> > it contro
Wanrong and Marc,
I (the author of current #3163 patch) was just in the middle of the
large email here explaining what I tried to do to create the tests,
and what I could not, and where I need help,... but was suddenly
stricken with the idea how I can write those tests. And the quick
experiments
Look forward to the new version.
>
> Wanrong
>
>
>
> Alex Myodov wrote:
> > Wanrong and Marc,
>
> > I (the author of current #3163 patch) was just in the middle of the
> > large email here explaining what I tried to do to create the tests,
> > and
is not caused by your patch, but something related
> to using inherited models.
>
> Thanks you for your work and I am hoping sometime soon you or somebody
> can get this nailed down.
>
> Wanrong
>
>
>
> Alex Myodov wrote:
> > Wanrong,
>
> > Just updated
I heard a suggestion once on the most natural rule to resolve such
problems. "django" and "django-hackers".
On 30 мар, 21:36, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> Considering how often people have to make this point on this list, maybe
> we could resolve the confusion by renaming this list
> So feedback is welcome, please give it.
Breaking the huge documents into smaller chunks for readability is
good... but please do leave the original huge ones as well! There are
cases where "a huge document" serves more help than "a bunch of
smaller ones" and really has its worth.
Opening /cache/
I am among the people interested in this patch.
But, looking at the patch concepts from the PostgreSQL perspective, I
wonder whether it will be possible to use it as a base of native
BIGSERIAL support in Django (it is likely that MySQL supports
something similar, but sqlite needs double-checking).
AIL PROTECTED]> wrote:
> On Fri, 2008-04-25 at 15:12 -0700, Alex Myodov wrote:
> > I am among the people interested in this patch.
> > But, looking at the patch concepts from the PostgreSQL perspective, I
> > wonder whether it will be possible to use it as a base of native
>
re its compatibility with the recent qsrf-
refactor merge. Can someone hint me please what more actions are
needed from me to help moving this patch further closer to the
inclusion?
With best regards,
Alex Myodov
--~--~-~--~~~---~--~~
You received this message beca
Being curious, had tried several benchmarks as well.
Indeed, the function-level imports have some overhead. But the
overhead becomes less and less important, as long as the function
complexity increases. If a function does nothing except import (as in
your case), the performance hit is several hun
18 matches
Mail list logo
