. Now
that we do 'require' it, we're making the effort. Its quite possible there
are others who would also benefit once implemented.
Thanks,
Anshuman
On 20 October 2014 13:14, Russell Keith-Magee
wrote:
> HI Anshuman,
>
> On Mon, Oct 20, 2014 at 2:03 PM, Anshuman Agg
ement without it, this isn't the case for a multi-object UPDATE as far
> as I can tell.
>
> Alex
>
> On Sun, Oct 19, 2014 at 11:34 PM, Anshuman Aggarwal <
> anshuman.aggar...@gmail.com> wrote:
>
>> Thanks for the input Javier. Wouldn't a similar argument ho
pdate queries
being collated into a single transaction.
On 20 October 2014 11:52, Javier Guerra Giraldez wrote:
> On Mon, Oct 20, 2014 at 1:03 AM, Anshuman Aggarwal
> wrote:
> > The idea of having a .update() ORM construct is to be able to do this
> > without having to fall down
ntil someone agrees with you. I've given you a specific
> course of action - provide performance benchmarks. Until you provide them,
> the only thing reposting like this will do is annoy the people you need to
> help you.
>
> Yours,
> Russ Magee %-)
>
> On Mon, Oct 20
Posting this Django Project ticket that I opened to track the enhancement
request to update multiple rows with different values for the same field
for a particular Django queryset in a single SQL query without having to
write raw SQL. Please see the discussion there.
https://code.djangoproject
Please see this enhancement request:
https://code.djangoproject.com/ticket/23646
Unlike what Russ has suggested, I'm pretty sure that a single UPDATE query
with a large number (Ks/Ms) of updates will be significantly faster than
doing multiple SQL UPDATE queries. If more people on the list feel
Hate to bump a thread, but any thoughts on the last proposal, Luke?
On May 20, 4:13 pm, Anshuman Aggarwal wrote:
> Usage would be: list_display = (ff('model__field__fkfield',
> short_description='FK Field') but ideally, the short_description
> should be optional with
Luke,
I completely agree on the need for change and personally +1 this as
it is a completely confusing historical annoyance.
However, as in all deprecation, I would suggest that we start with a
global setting that allows these links to be hidden on an installation
by installation basis and the de
else.
On May 20, 4:08 pm, Anshuman Aggarwal wrote:
> Hi Luke,
> Thanks for a detailed reply. I have gone over your points carefully
> and agree on most except a few key ones.
>
> Based on your response:
> - The question here is really how often is the guesswork right and
>
eld_name
if admin_order_field:
accessor.admin_order_field = admin_order_field
else:
accessor.admin_order_field = (field_name,)
return accessor
Regards,
Anshuman
On May 17, 11:35 pm, Luke Plant wrote:
> Hi Anshuman,
>
> On 17/05/11 14:42,
On May 17, 5:18 pm, Luke Plant wrote:
> On 17/05/11 12:20, Anshuman Aggarwal wrote:
>
> > Since the parent__child syntax is being used for list filter, search
> > fields and everywhere else, is there a reason why the list_display has
> > to be sacrosanct?
>
> Pl
I know this has been discussed (not sure to what depth) but callables
is not the solution. Please bear with me and help me (not force me) to
understand why what I am suggesting is wrong.
I did look in the list and have tried taking this discussion to the
ticket system. http://code.djangoproject.com
I know this has been discussed (not sure to what depth) but callables is not
the solution. Please bear with me and help me (not force me) to understand why
what I am suggesting is wrong.
I did look in the list and have tried taking this discussion to the ticket
system. http://code.djangoproject.
13 matches
Mail list logo
