On Mon, 3 Oct 2011 22:07:52 +0800
Russell Keith-Magee wrote:
> 1) Build your own experience with the internals of the ORM. As part
> of this learning process, document what you learn -- we would very
> much like to have better documentation of the internals of Django's
> ORM, but writing that do
or PendingRemoval?
On Mon, Oct 3, 2011 at 9:56 PM, Tai Lee wrote:
>
>
> On Oct 4, 11:17 am, Russell Keith-Magee
> wrote:
>> I'm completely agreed that the 'soft' deprecation is useful. I'm just
>> complaining about the ambiguity in the language: "We're deprecating
>> this feature by marking
Initially posted this to django-users, having completely forgotten
about the existence of django-dev. Sorry about that.
Currently, it is unclear as to how apps that override admin templates
should maintain compatibility with both 1.3 and 1.4 when referring to
the admin media file URLs in the overr
On Oct 4, 11:17 am, Russell Keith-Magee
wrote:
> I'm completely agreed that the 'soft' deprecation is useful. I'm just
> complaining about the ambiguity in the language: "We're deprecating
> this feature by marking it PendingDeprecation...".
What about just changing "PendingDeprecation..." to
"
Is this really much better than using your own custom manager as the
default automatic manager (used for reverse relations) with
`use_for_related_fields = True`?
Your custom manager could do nothing to filter results by default and
so behave the same as the default automatic manager, but provide
a
On Tue, Oct 4, 2011 at 9:40 AM, Joe & Anne Tennies wrote:
> I know that no one knows who I am, but I'm going to say that this is
> becoming a bike shed.
There appears to be some confusion here -- nobody is proposing
changing *anything* about Django's deprecation policy. All we are
doing is attemp
I know that no one knows who I am, but I'm going to say that this is
becoming a bike shed.
It sounds like there's generally agreement that people need to be warned
that something is going to be removed. It sounds like people that maintain
code that is required to be stable and relies on other peop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Luke,
Thanks for the thorough reply! I'm convinced that it wouldn't make sense
to merge select_related and prefetch_related; I wish I had a better
suggestion for a name for prefetch_related, but I don't. Consider my
concern withdrawn.
Carl
-BE
Hi Carl,
Thanks for the feedback, sorry for the length of my reply, I tried to be
detailed to avoid you having to read the code.
On 03/10/11 20:44, Carl Meyer wrote:
> My only real concern is one I'm a bit surprised hasn't been raised
> already: API and naming sanity. If I'm a new user coming to
On Tue, Oct 4, 2011 at 12:27 AM, ptone wrote:
>
>
> On Oct 1, 9:10 am, Luke Plant wrote:
>> Hi all,
>>
>> The Django deprecation timeline [1] is very inconsistent in its usage of
>> the terminology 'deprecated'. For example, the 1.5 section often says
>> "is deprecated" or "has been deprecated",
2011/10/3 Łukasz Langa :
> Wiadomość napisana przez Russell Keith-Magee w dniu 3 paź 2011, o godz.
> 16:07:
>
> 1) Build your own experience with the internals of the ORM. As part
> of this learning process, document what you learn -- we would very
> much like to have better documentation of the in
On Oct 3, 10:44 pm, Carl Meyer wrote:
> Hi Luke,
>
> On Oct 3, 9:04 am, Luke Plant wrote:
>
> > The patch for this is now ready, as far as I'm concerned, but I'd like
> > to bring it up here again before committing, mainly because Alex Gaynor
> > expressed some doubts.
>
> > The latest patch is o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/03/2011 08:05 AM, luk...@langa.pl wrote:
> `django.core.management.find_management_module()` has this description
> in the docstring that says it determines the path "without actually
> importing the application or the management module". Current
On Oct 3, 6:04 pm, Luke Plant wrote:
> Hi all,
>
> The patch for this is now ready, as far as I'm concerned, but I'd like
> to bring it up here again before committing, mainly because Alex Gaynor
> expressed some doubts.
I have done a review of the patch, and I think it is commit ready.
There has
Hi Luke,
On Oct 3, 9:04 am, Luke Plant wrote:
> The patch for this is now ready, as far as I'm concerned, but I'd like
> to bring it up here again before committing, mainly because Alex Gaynor
> expressed some doubts.
>
> The latest patch is on the ticket:
>
> https://code.djangoproject.com/ticke
Nice - didn't know about that, will check that out too.
Thanks for the feedback on this everyone!
Cal
On Mon, Oct 3, 2011 at 8:15 PM, Ian Kelly wrote:
> Have a look at the DatabaseOperations.max_in_list_size method, but it
> sounds like it's not going to be a simple constant for MySQL.
> On Oc
Nice - didn't know about that, will check that out too.
Thanks for the feedback on this everyone!
Cal
On Mon, Oct 3, 2011 at 8:15 PM, Ian Kelly wrote:
> Have a look at the DatabaseOperations.max_in_list_size method, but it
> sounds like it's not going to be a simple constant for MySQL.
> On Oc
Have a look at the DatabaseOperations.max_in_list_size method, but it sounds
like it's not going to be a simple constant for MySQL.
On Oct 3, 2011 1:01 PM, "Cal Leeming [Simplicity Media Ltd]" <
cal.leem...@simplicitymedialtd.co.uk> wrote:
> Ahh - max_allowed_packet pops up its ugly head again - it
Ahh - max_allowed_packet pops up its ugly head again - it
wouldn't surprise me if this was the case.
Thank you for testing this against Postgre - I will post the test results
against MySQL tonight/tomorrow.
Cal
On Mon, Oct 3, 2011 at 7:58 PM, Jacob Kaplan-Moss wrote:
> On Mon, Oct 3, 2011 at 1:
On Mon, Oct 3, 2011 at 1:31 PM, Cal Leeming [Simplicity Media Ltd]
wrote:
> So, came up against a strange thing today.
> Database backend is MySQL 5.5 (Percona variant)
>
> If I attempt to do an __in query with a list containing 50 thousand entries,
> the query wouldn't fail, but would instead ret
Ja - that was going to be my next step - bit stretched for time at the
moment - so was just a quick email to see if anyone had any thoughts.
I think even if it was a problem with MySQL - an error should have been
raised somewhere.
Either way - I'll build a test for it and let you know the results
On Oct 3, 2011, at 11:31 AM, Cal Leeming [Simplicity Media Ltd] wrote:
> I can provide exact further info, but this was just a preliminary email to
> see if this was expected behavior - or actually a bug??
You might try capturing the generated SQL and running it on a command line
against the D
So, came up against a strange thing today.
Database backend is MySQL 5.5 (Percona variant)
If I attempt to do an __in query with a list containing 50 thousand entries,
the query wouldn't fail, but would instead return no results. If I split it
up into chunks (say 100) - it would work fine.
For e
On Fri, Sep 30, 2011 at 4:37 PM, Johannes Dollinger
wrote:
> The aim of this proposal is to reuse Q objects for models that are related
> through FK or M2M fields.
i really want to have this feature! so i went and did a quick
implementation and created ticket #16979[1]
[1]:https://code.djangop
On Oct 1, 9:10 am, Luke Plant wrote:
> Hi all,
>
> The Django deprecation timeline [1] is very inconsistent in its usage of
> the terminology 'deprecated'. For example, the 1.5 section often says
> "is deprecated" or "has been deprecated", when what they mean is "will
> be removed", which is wh
Hi,
personally I am -1 on that, for the following reasons:
- This can be done in an external library
- You can't support every possibility, you want a string/int filter, I
want a blableblub/younameit type conversion
- playing with request.GET.* in templates is probably something you
Hi all,
The patch for this is now ready, as far as I'm concerned, but I'd like
to bring it up here again before committing, mainly because Alex Gaynor
expressed some doubts.
The latest patch is on the ticket:
https://code.djangoproject.com/ticket/16937
It is much longer than before, but mainly
There's numerous time where I found myself wishing for type casting
filters in templates..
For example, the following won't work because one is a string and the
other is an integer:
{% if request.GET.year == object.date.year %}
...
{% endif %}
So when I need to compare a string with an int with
Wiadomość napisana przez Russell Keith-Magee w dniu 3 paź 2011, o godz. 16:07:
> 1) Build your own experience with the internals of the ORM. As part
> of this learning process, document what you learn -- we would very
> much like to have better documentation of the internals of Django's
> ORM, but
Hey there.
`django.core.management.find_management_module()` has this description
in the docstring that says it determines the path "without actually
importing the application or the management module". Currently it
doesn't support namespace packages and there's a long open ticket
about it [1].
M
On Mon, Oct 3, 2011 at 2:40 AM, Sebastian Goll wrote:
> Hello,
>
> I'm afraid I'll have to reply to my own message because nobody else did. ;)
> Please read on. Also, please note that the original report is now over five
> weeks old, with no real solution yet in sight.
>
>
> On Thu, 29 Sep 2011
On Sun, Oct 2, 2011 at 12:10 AM, Luke Plant wrote:
> Hi all,
>
> The Django deprecation timeline [1] is very inconsistent in its usage of
> the terminology 'deprecated'. For example, the 1.5 section often says
> "is deprecated" or "has been deprecated", when what they mean is "will
> be removed",
On 10/03/2011 01:05 AM, Paul McMillan wrote:
Isn't there also the possibility that the attacker can somehow get arbitrary
data signed into the session cookie without knowing SECRET_KEY?
That's not a viable attack route. It's much less likely than a
developer exposing their SECRET_KEY.
Now that
As a native speaker, I've never had a problem with the words or
phrases being discussed here. Sure, it's jargon. It might be more
accessible if we used other language. I don't really care one way or
the other. But it's jargon. The fact that Miriam-Webster doesn't know
what the word actually means d
34 matches
Mail list logo
