On Thu, Dec 17, 2009 at 2:56 AM, Leaf wrote:
> I know that you are all busy, but it has been over two weeks and there
> has been no activity related to ticket #12292 (render_to_response
> method on AdminSite and ModelAdmin) either on the list or on the Trac.
> Has anyone looked at the ticket? What
On Wed, Dec 16, 2009 at 4:51 PM, SmileyChris wrote:
>
>
> On Dec 17, 8:57 am, Alex Gaynor wrote:
>> On Wed, Dec 16, 2009 at 2:53 PM, Mike Malone wrote:
>> > How's that different than the current situation, where we return an
>> > absolute URL reference that can be converted into an absolute URL
On Dec 17, 8:57 am, Alex Gaynor wrote:
> On Wed, Dec 16, 2009 at 2:53 PM, Mike Malone wrote:
> > How's that different than the current situation, where we return an
> > absolute URL reference that can be converted into an absolute URL
> > using request.build_absolute_uri?
>
> It allows an objec
On Wed, Dec 16, 2009 at 2:53 PM, Mike Malone wrote:
> On Wed, Dec 16, 2009 at 11:10 AM, Alex Gaynor wrote:
>> On Wed, Dec 16, 2009 at 2:02 PM, Mike Malone wrote:
The way i see it (which may be wrong), this is not a proposal to make
the request object global or replace/refactor the cont
On Wed, Dec 16, 2009 at 11:10 AM, Alex Gaynor wrote:
> On Wed, Dec 16, 2009 at 2:02 PM, Mike Malone wrote:
>>> The way i see it (which may be wrong), this is not a proposal to make
>>> the request object global or replace/refactor the contrib.site app. In
>>> fact, some of the use cases mentioned
On Wed, Dec 16, 2009 at 1:04 PM, Karen Tracey wrote:
> I've uploaded what I think is a commit-ready patch for adding
> BigIntegerField. Barring any major objections I'd like to commit this in
> the next day or two.
Looks good to me - go ahead.
Jacob
--
You received this message because you ar
On Wed, Dec 16, 2009 at 2:02 PM, Mike Malone wrote:
>> The way i see it (which may be wrong), this is not a proposal to make
>> the request object global or replace/refactor the contrib.site app. In
>> fact, some of the use cases mentioned strike me as things that would
>> require overriding the d
I've uploaded what I think is a commit-ready patch for adding
BigIntegerField. Barring any major objections I'd like to commit this in
the next day or two.
Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send
> The way i see it (which may be wrong), this is not a proposal to make
> the request object global or replace/refactor the contrib.site app. In
> fact, some of the use cases mentioned strike me as things that would
> require overriding the default get_absolute_url method anyway. It
> seems to me l
I know that you are all busy, but it has been over two weeks and there
has been no activity related to ticket #12292 (render_to_response
method on AdminSite and ModelAdmin) either on the list or on the Trac.
Has anyone looked at the ticket? What are the chances that this will
make it in for 1.2?
R
On Wed, Dec 16, 2009 at 12:08 PM, Jacob Kaplan-Moss wrote:
> On Wed, Dec 16, 2009 at 10:13 AM, Jeremy Dunck wrote:
>> This won't work, because deferred fields are descriptors, and
>> accessing foo.field would run the query.
>>
>> Something you could do is foo.deferred_fields.field_name -> Boolean
On Wed, Dec 16, 2009 at 10:13 AM, Jeremy Dunck wrote:
> This won't work, because deferred fields are descriptors, and
> accessing foo.field would run the query.
>
> Something you could do is foo.deferred_fields.field_name -> Boolean,
> but that seems pretty clunky to me.
You can get at this infor
On Wed, Dec 16, 2009 at 10:02 AM, Anssi Kaariainen wrote:
...
> I am not suggesting this. What I would like to have is something like
> foo.field.is_deferred(). I don't think there is any easy way to test
> this currently. This could come handy in a template for example. You
> could use the same t
On Dec 16, 4:34 pm, "Sean O'Connor" wrote:
> Nice work Russ! Got to love when something goes from "nice to have" to
> "done".
>
> Anssi, I don't think I understand your use case. Even if an unmanaged model
> doesn't have a literal table behind it, it needs something which at least
> resembles a
On Wed, Dec 16, 2009 at 6:51 AM, Russell Keith-Magee
wrote:
> No need for workaround docs - I've just uploaded an RC3 patch that
> implements deferred fields.
Sweet! I love it when other people do my work for me...
> The one gotcha on this patch is that it now requires that you request
> the pri
Nice work Russ! Got to love when something goes from "nice to have" to
"done".
Anssi, I don't think I understand your use case. Even if an unmanaged model
doesn't have a literal table behind it, it needs something which at least
resembles a table (i.e. a view) to query against. Otherwise the OR
On Wed, Dec 16, 2009 at 8:19 AM, Anssi Kaariainen wrote:
...
> A nice way to test which fields the model
> were populated and marking the non-populated fields as deferred would
> be optimal in my opinion. One use case where you don't necessary know
> which fields are populated and which ones aren
On Dec 16, 2:51 pm, Russell Keith-Magee
wrote:
> On Wed, Dec 16, 2009 at 7:56 PM, Jeremy Dunck wrote:
> > On Dec 15, 2009, at 11:16 PM, "Sean O'Connor"
> > wrote:
>
> >> In regard to the deferred fields option, I'll let Jacob speak for
> >> his view but I've approached such functionality as "n
I have made some progress on http://code.djangoproject.com/ticket/6148
and got it back in sync with trunk.
I would like someone to have a look at it and see if it's inclusion
ready.
Thanks in advance.
Peter
--
You received this message because you are subscribed to the Google Groups
"Django dev
On Wed, Dec 16, 2009 at 7:56 PM, Jeremy Dunck wrote:
> On Dec 15, 2009, at 11:16 PM, "Sean O'Connor"
> wrote:
>
>> In regard to the deferred fields option, I'll let Jacob speak for
>> his view but I've approached such functionality as "nice to have"
>> for the patch since its not critical to the
On Dec 15, 2009, at 11:16 PM, "Sean O'Connor"
wrote:
> In regard to the deferred fields option, I'll let Jacob speak for
> his view but I've approached such functionality as "nice to have"
> for the patch since its not critical to the patch being useful.
> Personally I haven't had the ti
I already created ticket for this http://code.djangoproject.com/ticket/7220
veena
On 14 pro, 23:59, Sergiy Kuzmenko wrote:
> I wonder if there is a particular reason why last_login field of is not
> defined as "null=True"? It makes sense to me to have it as null which would
> mean that the user
22 matches
Mail list logo
