Re: "Delete selected objects" in admin batch edit

[kmike]

Totally agree, bulk delete shouldn't be enabled by default.

One more issue with that: it is nice to be able to define actions
order in drop-down list. It can be achieved with very simple patch,
see http://code.djangoproject.com/ticket/10734 . But if we have delete
action (or any other action) enabled by default, this patch will
always put it at top and we will have to overload "get_actions" method
again to fix it.

--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: "Delete selected objects" in admin batch edit

[Alex Gaynor]

On Sat, Apr 4, 2009 at 7:10 PM, kmike  wrote:

>
> Totally agree, bulk delete shouldn't be enabled by default.
>
> One more issue with that: it is nice to be able to define actions
> order in drop-down list. It can be achieved with very simple patch,
> see http://code.djangoproject.com/ticket/10734 . But if we have delete
> action (or any other action) enabled by default, this patch will
> always put it at top and we will have to overload "get_actions" method
> again to fix it.
>
> >
>
It seems to me that the default behavior of including items from every
parent class is causing more harm than good.  I'm very tempted to say we
might be better off just requiring users to either relist every item or do:

class MyModelAdmin(ModelAdmin):
actions = ModelAdmin.actions + ['my_action']

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Dallas 1.1 sprint - dates?

[Justin Bronn]

On Apr 3, 9:50 am, Jeremy Dunck  wrote:
> Gary, Justin?
>

The 17th option is better for me, but at this point it's still not
looking like I'll be able to make it.
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSoC - denormalization model field proposal

[christian schilling]

2009/3/22 Daniel Tang 

>
> On Sun, Mar 22, 2009 at 11:55, Christian Schilling
>  wrote:
>
> > 2) a API like the current django-denorm to turn functions into fields.
> > this could work by creating a model DirtyInstance that contains
> > nothing but a generic FK
> > when such a field is used it should then create a trigger that adds
> > rows to the dirty_instance table pointing to all instances that may
> > contain fields that need updating.
> > After the update is complete a updater function then can iterate over
> > this rows, doing the updates and deleting the rows in the
> > dirty_instance table.
> > Alternativly this could be done by a daemon or a cronjob.
>
> This could work, but is it really going to perform better than a
> SELECT; UPDATE? Jacob pointed out that the database could change
> between the SELECT and UPDATE (I think that's what he was saying,
> anyway), but I don't think this is a problem. The SELECT set is used
> to approximate the set being updated. If the computation being done on
> the row is deterministic, then it could result in some redundant
> updates on the denormalized fields. If the SELECT set is used strictly
> for denormalization and not exposed by a public signal, then I don't
> think the fact that the SELECT is an approximation of the UPDATE is a
> big problem.
>
> The speed issue is still a problem, but I have doubts about it being
> slower than your method, since yours is more like
> UPDATE;INSERT;...;INSERT;SELECT. In order to reduce the speed issue, I
> think signals would have to support some sort of lazy execution, so
> nothing is done if there are no listeners/no listeners for the sender.
>
>
i implemented both aproaches (branches on github) and did some
simple benchmarking (just using the models from the tests creating a number
of rows
doing update() on them) and it seems the second implementation
(triggers filling dirty_instance table + lazy updates) is a lot faster than
the first implementation
using signals, plus it does not require any monkeypatching.

the trigger itself has only very low impact on the execution of update() and
most of the time
is used for actually updating the fields.

one other thing:
i think in adition to the use cases 1) AgreateField 2) MirrorField 3)
"cumputation" field
there is a fourth one that has not been mentioned in the disscussion:
4) CountField
i don't mean an  AgregateField agregateing a count, but rather a field that
gets incremented/decremented
at the right times.

--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: CSRF template tag patch done

[Luke Plant]

Hi Jacob,

Just got back from being away, would have replied earlier otherwise...

> It's simply far too draconian: if I forget to do all steps needed
> to upgrade, all my contrib apps stop working. And then as soon as I
> *do* those steps, all *my* apps that use POST stop working. I just
> can't see that causing anything other than a huge amount of pain
> for all but the most savvy users. Updating every view that handle a
> POST is a *lot* of work for even small apps.
>
> An even bigger problem would be for users of third-party reusable
> apps: my personal blog is a mere 645 lines of code, but there's
> over 10,000 lines of third-party apps I'm building on top of. If I
> want to upgrade to 1.1 and keep using the admin, I need to wait for
> all of those apps to be upgraded to use CSRF protection.

I don't think it is quite so drastic, there are some more alternatives 
here that I think you've missed (my fault for not explaining clearly).  
Here are two ways to keep things 'working' with minimal effort (these 
are scenarios 5 and 4 in my previous email):

1) Install the CSRF app (update INSTALLED_APPS and 
TEMPLATE_CONTEXT_PROCESSORS), but don't install the middleware.

Result: everything still works, but no CSRF protection.

2) Install the CSRF app (update INSTALLED_APPS and 
TEMPLATE_CONTEXT_PROCESSORS), and install *both* CsrfViewMiddleware 
and CsrfResponseMiddleware.

Result: everything still works, including automatic CSRF protection as 
it was in Django 1.0 (and template tag protection for contrib apps as 
well).  Performance: you get the performance hit of the old post 
processing method.  Completely harmless side effect: you get double 
insertion of the CSRF token in the contrib apps (this works fine, it 
isn't even invalid HTML).


It seems to me the only two alternatives you could be proposing are:

1) No recommended CSRF solution.

Result: everything works, but no CSRF protection.

2) Recommend using the Django 1.0 CsrfMiddleware

Result: everything works, including automatic CSRF protection, with 
its nastiness.

I don't think that 'my' options 1) and 2) are so much worse than 
'your' 1) and 2)  (not wishing to sound aggressive there!)

So, as I see it the only disaster is if people expect to upgrade to 
Django 1.1 without changing any settings, and don't even do basic 
tests (like loading any page in the admin that has a form in it).

Of course, you would still want all apps to be updated eventually.  
The evil thing is that once updated for the Django 1.1 way, they would 
stop working with Django 1.0, due to the presence of {% load csrf %} 
and {% csrf_token %} in their templates.  This is actually the 
nastiest part of the whole thing IMO, but I think it affects lots of 
other areas and is fairly inevitable -- any app which is changed to 
use Django 1.1 features will break if you run it on 1.0.  

I'm sorry if I didn't explain this properly, it's a bit involved and 
easy to forget that other people haven't thought about it for hours!  
I realise we would need to document the above very clearly, I'm not 
sure where info about upgrading needs to go.

I did go through my own external applications and update them, BTW, 
and found the process pretty painless (just "ack -i '