till don't have an order relative to each other, so if we
change the code in Django that does order resolution even slightly it could
result in different operation orders or even different "final" rendered
models.
Andrew
On Mon, Sep 7, 2015 at 5:16 PM, Shai Berger wrote:
> O
so on. There's nothing blocking
it from what I know - it shouldn't be too hard to take the loaded operation
set and run the optimiser on it before it's applied.
Andrew
On Fri, Sep 11, 2015 at 2:38 AM, Christian Hammond
wrote:
> Hi everyone,
>
> We're working on upgrading
I think if the fix is easy, we should continue to support them past 1.7,
since we're retaining syncdb support. However, if it's crazy complicated,
it's likely not worth it.
Andrew
On Wed, Nov 4, 2015 at 11:59 PM, David Filipovic
wrote:
> I have initially created
That's an excellent point, Shai - if there are migrations they might be
essential to the app functioning. I think in that case we should not have
them work on 1.7 and up, and encourage people to send PRs to the apps
moving the directory name if it would work with syncdb.
Andrew
On Sat,
; for correctness reasons, you really shouldn't be anyway.
There was some work on adding a "MIGRATE" option to be stuck in the TEST
key for databases, but it's not landed yet and wouldn't be till 1.10 anyway.
Andrew
On Wed, Nov 11, 2015 at 12:59 PM, Tim Graham wrote:
> Hi, ha
I also agree this looks sensible - I think South even had an attribute like
this on the migration class, it just never got ported over. +1
On Tue, Nov 24, 2015 at 8:19 AM, Marc Tamlyn wrote:
> +1 to idea and API. I've wished I had this recently - even if it's just so
> I can check up on the prog
target migrations as well,
potentially?
Andrew
On Mon, Nov 30, 2015 at 7:33 PM, Silvio wrote:
> I've had this situation come up too. It would indeed be very useful.
>
> Django South had something vaguely related:
>
> http://south.readthedocs.org/en/latest/tutorial/part3.html
e the twin-tip check on the migrate command if you're asking to reverse
one of those tips; that should solve that issue.
Andrew
On Wed, Dec 2, 2015 at 2:48 PM, Shai Berger wrote:
> On Tuesday 01 December 2015 08:40:34 Andrew Godwin wrote:
> > You can undo a migration manually using
ngo, as well as hopefully release a pluggable app
version that will run on 1.8 and 1.9 - I have some plans around how to do
that effectively, but they involve hitherto unforged paths around Django
and how we package dependencies, so I can't say we'll get there 100%.
Andrew
--
You re
an at-most-once delivery style, which
will work for operations that aren't critical, or if people build their own
retry logic (but at that point, maybe use Celery).
Andrew
On 16 Dec 2015 07:32, "Shai Berger" wrote:
> On Wednesday 16 December 2015 08:08:59 Markus Holtermann wrot
involved".
>
I don't agree; I think it's more "do you have enough workers to handle
this". Channels makes all workers serve all requests, so if you're doing
e.g. video encoding you can't segregate it from request handling. However,
you could have multiple c
approaches (I've been prototyping bits of this for years); this
approach ended up being the nicest design and the one I have the most
confidence in that we can scale and shard to large work volumes.
Andrew
On Thu, Dec 17, 2015 at 10:30 AM, Samuel Bishop
wrote:
> I'm uncertain how po
asing part of
it as a separate codebase, though still under the Django umbrella.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from
was basically unused by anyone these days, but hey,
happy to be proved wrong. Do we have any usage numbers on it to know if
we'd need it for a new standalone server to implement? It's really not hard
to add it into the request format, just thought it was one of those CGI
remnants we m
wrote:
> On 12/17/2015 11:50 AM, Andrew Godwin wrote:
> > - I thought SCRIPT_NAME was basically unused by anyone these days, but
> > hey, happy to be proved wrong. Do we have any usage numbers on it to
> > know if we'd need it for a new standalone server to implemen
over
is slightly less verbose than normal HTTP and needs less work to use, but
it's not a big saving)
Andrew
On Thu, Dec 17, 2015 at 9:01 PM, Anssi Kääriäinen
wrote:
> Is the idea a large site using classic request-response architecture would
> get the requests at interface servers,
m to the client).
It does mean going a bit beyond the normal dictionary interface for a
message to allow a way to stream the contents of a key rather than just
read it, but I think that would be easy-ish to do.
Andrew
On Thu, Dec 17, 2015 at 11:13 PM, Sam Willis wrote:
> Hi,
>
> To s
sts.
I think Django absolutely has to adapt to the modern web environment and
move away from just rendering templates when browsers request them, and
this to me is part of that. If there are other solutions to the same
problems I think we should consider them as well; I've just not run across
any
eople will want to turn on, and that provides a lot of value
in exchange for a slight round-trip performance hit - my goal is sub-5ms,
and preferably sub-3. If it starts being 10/20/30 milliseconds of cost,
then we'll have to change our approach until it's acceptable.
If you don't want
ct handling are basically indistinguishable from the
outside.
I'll work on another draft that more clearly highlights WSGI and direct
request handling in the "keeping Django the same part" - hopefully that
will help make things clearer.
>
> Andrew, I thank you for your patience
On Fri, Dec 18, 2015 at 5:28 PM, Anssi Kääriäinen
wrote:
> On Friday, December 18, 2015, Andrew Godwin wrote:
>
>>
>>
>> On Fri, Dec 18, 2015 at 3:44 PM, Mark Lavin wrote:
>>
>>> > You seem to be assuming I'm here to foist a brand new middle layer
ven channel in both the redis and database backends, which is a good
rough metric, though in systems like this I do prefer to know queue time
(i.e. how long are items on the queue before consumption) - that's a lot
harder though.
Might be a good idea to carve out a channel_length() API on backe
On Mon, Dec 21, 2015 at 6:05 AM, Samuel Bishop wrote:
> Hi Andrew,
>
> Thanks for the detailed response. I'm glad to hear you have tried a few
> different ways to implement this, and having read through your reply, and
> the channels docs again, I have more questions :-)
documentation and so forth. Any radical change that
might end up happening would have to happen in slow steps over many
releases, and only with the buy-in of the community - I don't even fully
have that yet, and I don't expect to get it until Channels can show that it
works, is backwards-compa
email for each distinct one. It's definitely better than the
current situation though. It also relies on you having a cache backend
set up.
Unfortunately I never did get time to write unittests for it, and
unittesting something like this is quite hard because of the timeout
involved.
Hope this i
ing Django shipping a base view which just calls a
request method, and then another base view which inherits from that and
does method-based dispatch - we shouldn't add too many classes, else
it'll be a documentation nightmare, but that seems a sensible split.
Andrew
--
You received
#x27;t do that unless someone thought to pass those
variables in initially in the method signature.
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develop...@googlegroups.com
e people here seen
to want to have that kind of purity at the expense of usability -
dammit, Jim, I'm an engineer, not a mathematician.
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send emai
t anything actually sensitive in there).
(There's also the issue of whether you apply context processors to the
JSON replies, and so forth, but that's going even further down the
rabbit hole)
Andrew
--
You received this message because you are subscribed to the Google Group
ded code; as that gist demonstrates, we can use their
functionality now, just without the syntactic sugar that "with:"
provides, and then when we eliminate 2.4 support, move over to using
them internally as well; in the meantime, we bring potential joy and
happiness to the significant number
e on the
ModelAdmin class to point to a different template which itself inherits
from admin/change_list.html, rather than having two with the same name,
which could be potentially confusing.
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
develop
and I think it's a mature enough implementation that
we're better off landing it and getting feedback than putting it in a
special corner and bikeshedding a bit more. I'd rather get feedback from
the userbase at large, which I think is where we'll really learn what
needs cha
, ' %} ', 'endfoo ', '']
(the key here is asserting the even number of quote marks, something a
regular language is capable of expressing)
It's a bit early in the morning for in-depth regexes, but that seems to
show that it is _probably_ possible. Wheth
d we don't change current behaviour.
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+uns
the
current way as well).
As for the naming problem, I always, always name my views in the URLconf
- I find that using the class name is just fragile, since you can't
easily rearrange views into a package. The docs are already encouraging
this approach, but perhaps we should make it clearer in
.X backport, or the main trunk version?
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
d
On 27/10/10 12:15, Simon Meers wrote:
> On 27 October 2010 19:40, Andrew Godwin <mailto:and...@aeracode.org>> wrote:
>
> On 27/10/10 07:01, Simon Meers wrote:
>
> Has anyone else found that using prepopulated_fields in
> admin.ModelAdmin since r
': {
'ENGINE': 'django.db.backends.oracle', # Add 'postgresql_psycopg2',
'postgresql', 'mysql', 'sqlite3' or 'oracle'.
'NAME': 'XE', # Or path to database file if usi
#x27;s an excessively ugly
thing to add one more option/subclass, especially when the resulting
error is quite user-unfriendly ("This value must be unique" error beside
a non-required, blank textbox).
Thoughts?
Andrew
--
You received this message because you are subscribed to the Goog
I just ran into this same issue, but it wasn't Django, the answer
lived in nginx.conf
try checking the
client_max_body_size M;
in your server{
On Nov 10, 9:42 am, john <185...@gmail.com> wrote:
> Hello,
>
> I'm working on a Django project. I'm running on cloudservers hosting,
> with nginx/uwsgi a
uot;" for empty strings since the start, which can be a divisive
issue amongst the developers I know. Something to chalk up for the
fabled Django 2, perhaps.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
7;t even cause more work for responders as they have to change the
state back - it just does.
I'm +1 on adding this, but that's definitely biased by the fact that it
makes the two Tracs I use on a regular basis more similar.
Andrew
--
You received this message because you are subsc
On 15/11/10 01:35, Russell Keith-Magee wrote:
On Sun, Nov 14, 2010 at 5:22 PM, Andrew Godwin wrote:
On 13/11/10 16:52, Daniel Moisset wrote:
Hi,
while working on the sprint today doing triaging we noticed that a
lot of tickets were in the "Unreviewed" state becaus
ADMIN_MEDIA_PREFIX setting
> will be removed, and the admin media will be assumed to be served at
> STATIC_URL/admin.
>
> Any objections to this plan before I put it into action?
>
> Carl
>
+1 from me; sounds like a good plan. The whole
admin-media-special-case-thing has been
personal projects, and I figured it
was better to ask people while the idea was fresh in my mind.
(Also note the above implementation plan is very rough. Criticism of it
is very welcome.)
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers
wanted to see what people's initial reactions were (namely, "class
based views makes this a more real issue").
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develo
ame. We could always just call them Http409
or something, but I see that as less readable (not everyone immediately
knows 409 is a conflict, for example).
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this gr
hat's something I'm happy to look at when I start doing the
migration-ish merging early next year - it may not need that many
changes at all, as opposed to this, so I'm firmly +1 with (4) as the
"it's an extra setting, but literally nobody will use it" option.
And
ikely to occur.
My suggested workaround is to add a pre_save hook that manually fixes
the fields up. Someone I know has one that runs against all saves on all
models, and auto-corrects any "" values in nullable fields to None
before saving them.
Andrew
--
You received this message
rks gradually move towards best practices it'll become increasingly
difficult to tell them apart. This is definitely a good thing, I am generally
rather pleased if I can deploy something without someone knowing what server
side tools are in use.
- Andrew Ingram
--
You received this me
sistent? I can't see that really breaking any code
written in the past few weeks, as people will be looking for the page
object anyway.
For reference, the offending lines:
if paginator.num_pages > 1:
...
return (paginator, page, page.object_list, True)
else:
return (None, None,
se class, and get the functionality on the views you want.
I'm -1 on the generic views accepting GET for form submissions, for the
GET-modifying-data-is-bad reasons above. That doesn't, however, stop you
from using it as a mixin, and if you find any design issues with mixing
in new behavio
Models with a BooleanField are instantiated with that field's value
set to False if no default or initial value is provided. Instead, like
most other fields, the field's initial value should be set to None.
This None should be left uncoerced when attempting to save the
instance, so attempting to sa
e desired behavior. We just don't know whether they serve
hot dogs. I've been there once but it was a long time ago.
#6755 seems unrelated to this issue ("Model Inheritance doesn't work
in the admin"). Haven't tested on other databases.
Andrew
--
You received this me
mpt this you'll need to have a decent
knowledge of SQL, the various database backends, and at least the usage
of the Django model layer - this is an area where several have tried and
not got very far, so it takes a little bit of determination and a
willingness to delve into some of the more
k English as a
first language. *That's* not a problem; we're not going to be grading
you! However, we need to see that you can communicate clearly, and so
basic proofreading is a must.
Next steps
--
If you've read all that -- and congratulations, by the
just want to customise how the serialiser outputs
DateTimeFields, or tell it how to serialise my new, shiny, custom field
- does your proposal have any way to override things on a field type basis?
Those are my initial reactions on the first reading of the proposal with
your change to authenticat
rejected.
Mentors, make sure you're also entered at the top of the wiki page (you
also have longer to sign up - until April 22nd, when we'll need to have
assigned all successful projects mentors):
http://code.djangoproject.com/wiki/SummerOfCode2011
Andrew
--
You received this message b
se issues, I look forward to seeing a
GSoC proposal. Don't expect it to get through without some serious
debate, however.
Andrew
[1]:
http://code.djangoproject.com/browser/django/branches/soc2010/query-refactor
--
You received this message because you are subscribed to the Google Groups
11am on the West Coast, so don't think you've got all Friday!
There's been some good discussion already this year, and we're looking
forward to your proposals!
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django dev
t; you're allowed to update the submitted proposal
right up until the deadline, so it doesn't need to be perfect on the
initial submission. If you don't submit your proposal in time, you'll be
unable to take part in this year's GSoC.
Happy proposal-writing.
Andrew
me then; we'll hopefully have weekly updates from each student, so
you know how they're getting on. It looks to be another good summer for
Django!
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
take
advantage of it for free.
This is only one use case, but I'm sure there are more. I'm happy to
try and come up with a patch if there's some agreement on this.
The FormSet views I've developed can be seen here:
https://github.com/AndrewIngram/django-extra-views/blob/maste
trying to think of a more straightforward
test case that isn't tied to my ModelFormSetView.
- Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/djan
On 9 Jul 2011, at 10:44, Sam Lai wrote:
> I concur. The consensus seems to be shifting towards a 'strip' flag
> though (defaulting to false), and I'm +1 on that. That would make it
> explicit, minimise repetitive boilerplate code and also make it less
> likely to accidentally forget to strip a fie
this ticket:
https://code.djangoproject.com/ticket/16432), but it's fairly
feature-complete and could be a good starting point.
- Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to d
Hello,
It would be of great help to me if the ability to pass variables
through HTTP GET were possible within the admin changelist view. For
example, I use Django admin tools to manage security advisories that
come from various sources. I need the ability to create a "meeting
view," which essent
often run into errors that result in a failed import of a view module,
and the tracebacks don't show the original fault without this patch.
Cheers,
Andrew.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Dja
rted from trunk. I'm really looking forward to
moving to 1.0 when it's released (possibly even when there's a release
candidate), particularly for QSRF and the full unicode support
throughout.
Speaking of sprints, are there any plans
This way, most people will be satisfied by the shipped functions (which
are somewhat analogous to generic views, in a very very roundabout way)
and people who Love Control™ can roll their own.
Just my two cents. I'll scuttle back to migrations libraries now.
Andrew
--~--~-~--~~--
o-extensions (which
involves keeping the horrid hacks in there), into a separate app but
with patches to core to make it less hackish (i.e. more signals), or add
it as my 1.1 pony with the proviso that I'm happy to write all the code.
Andrew
--~--~-~--~~~---~--~--
ggregate denormalisation will work with any
future extended aggregate support, but if the field just takes a normal
QuerySet, that might Just Work™.
Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django deve
ually end up with the best
of both worlds, and get people using more efficient schemas first, which
they can then easily bake into triggers when they come along, and if
their DB supports them.
Andrew
Steve Holden wrote:
> This appears to be a proposal to re-implement triggers inside Djang
to change the field names, too, CopiedField especially is a
little clunky.
Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@
, and
return a result - when you use these, though, you have to also specify
the column type of the resulting column. Docs for all this will be
written in time.
So, what does everyone think? Useful, or just too much of an edge case?
Reasonable patch, or badly implemented?
Andrew
[1]: As an examp
since detecting these is far more efficient.
I'd love to see any proposal for how Aggregates should look, as my
current incarnation really isn't too django-ish. I personally like
MirrorFields (now on their third name, more welcomed) as I have them
now, but then I would, since I invented t
thanks Dan I had used tabs instead of spaces, I will subscribe to
django-users for future problems
Andy
On 31 Oct 2008, at 14:46, Dan Fairs wrote:
>
> Sorry - should also have mentioned that this should be on django-
> users.
>
> On 31 Oct 2008, at 14:28, Opel wrote:
>
>>
>> I have been fol
;count")
i.e. the same call, but different syntax.
I might just go open a ticket for this soon anyway to get it recorded
properly, and at the very least release the code as a standalone module
- it's written so it can work like that anyway.
Andrew
--~--~-~--~~~-
#x27; thing, though. However, I like the
filter()-style syntax, I'll need to see if that's easy enough to roll in
so it still makes sense...
Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django
model needs updating (for
example, if you know that the field "planet" on the just-saved object is
a foreign key to your model).
Still, I certainly like the idea of having a decorator syntax; I'm going
to go away and see if I can persuade my AggregateField to turn
inside-out like that
and more, especially as we can then just build 'AggregateFields' on top
of them.
Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
e
for my denorm code I'd be happy to port over (it has the wonderful set
of tricks you need to unit test with a whole fake app, while still
keeping database settings) if you want.
Andrew
Christian Schilling wrote:
> i spend some time implementing my idea above (still just a proof of
> co
est 'suite' is hardly finished yet (one test...), but it does
at least do a pretty thorough use check of some of the more basic
scenarios. ./manage.py test denorm does indeed test and come out OK,
though - it even brought up an infinite recursion bug I also had in my
code, which I've
up a trac instance somewhere...
I have a Trac setup around on my server for South, so if you want I'll
kick that slightly and install the Git plugin...
Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
&q
of the migration's .py file), but we never followed
it through; I'm beginning to think it might be worth it, since many
people know and sometimes even love the good old ORM.
Also, Russ, #7835 would be very welcome, and reduce the need for my
(somewhat hackish) unit test suite that does inde
y more than that, but it
> doesn't look like there's enough work here for a GSOC project.
There was a more promising solution than mine, as well -
http://github.com/initcrash/django-denorm/tree/master - where you just
write a function and stick a decorator around it to make it w
common problem, and we could
easily come up with a neutral page to point people at all their options,
rather than leaving them to find that wiki page on their own.
Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Group
Hello
Sorry, this is probably a silly question but I'm fairly new to
python/django. Is it possible to have django 1.0.x and the svn version
installed side by side and if so, how do I achieve this?
The reason I ask is that I'm developing production code against 1.0.x. I've
found a bug in that vers
Thanks, and sorry for posting to the wrong list!
2009/4/29 Alex Gaynor
>
>
> On Wed, Apr 29, 2009 at 6:23 PM, Alex Gaynor wrote:
>
>>
>>
>> On Wed, Apr 29, 2009 at 6:08 PM, Andrew Smith wrote:
>>
>>> Hello
>>>
>>> Sorry, this is pr
ven't been able to locate them. Any pointers on where I can find
these? Or do they not exist?
Much thanks!
-- Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
True, but since I need to write a test anyway to make sure things are
working, I might as well include it. Just wanted to make sure there
wasn't already a pre-determined spot to insert it.
On Jul 20, 7:57 pm, Russell Keith-Magee
wrote:
> On Mon, Jul 20, 2009 at 9:45 PM, Andrew Fo
On Tue, Aug 11, 2009 at 10:50 AM, Richard
Davies wrote:
>
> Hi all,
>
> With 1.1 out of the door (great!), here's a thought for 1.2...
>
> I often end up writing the same couple of template tags and filters. I
> think some of these are general enough and useful enough that they
> should be conside
onald linked would be a lot easier to emulate, so I'm
not that against it.
Andrew
On Sat, May 18, 2013 at 7:15 PM, Donald Stufft wrote:
> There's already a patch on the ticket tracker for a pre_syncdb signal, and
> yesterday I started updating it and modifying it a bit as I
uot;migrate"
in its default configuration, and would do exactly what you would expect
(whereas with South now, and with option 2, syncdb doesn't do enough).
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubs
e present for an app, it will always
create new databases by running through them from the very first migration
to the latest one.
The proposed "squash" feature helps stop any potential long setup times
(from hundreds of migrations) by allowing you to replace 100 old ones with
a few new
d to a
non-migrated app, but not vice-versa.
Andrew
On Fri, May 31, 2013 at 8:22 AM, Anssi Kääriäinen
wrote:
> On 05/31/2013 09:55 AM, Mantas wrote:
>
>> Quoting
>> django-developers@**googlegroups.com(2013-05-31
>> 07:39:24)
>>
>>> From: Andrew God
igrations for tests - as I believe we
should be making people do this as a general case - and if you want, having
the data migration operations have an option you can pass where they no-op
during tests, something like:
operations = [
Python(
"""
for author
o be useful
and how fast the migration optimiser/compressor that runs on the squashes
will be.
Andrew
On Fri, May 31, 2013 at 1:38 PM, Marc Tamlyn wrote:
> I have generally not kept my migrations so they always work from scratch
> for similar reasons Luke said - Data migrations are often de
Hi Group,
could someone please help me with -
http://stackoverflow.com/questions/17184386/providing-admin-actions-to-group-members-in-a-multi-tenant-django-crm-applicatio
Thanks!
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubs
to merge it now as merging changes back in from
master is becoming trickier and trickier.
You can see the pull request here:
https://github.com/django/django/pull/376
I'd be aiming to merge this early next week, dependent on feedback.
Andrew
--
You received this message because you a
201 - 300 of 630 matches
Mail list logo
