Filtering on Many2Many Related Objects
Hello all,
Earlier I was trying to filter for objects that had a set of other
objects related to them by a ManyToManyField. It's a bit awkward, and
I have a couple of proposals to improve it.
Consider the following models:
class Person(models.Model):
name = models.CharField(max_length=128)
class Group(models.Model):
persons = models.ManyToManyField(Person)
Consider a group g containing Persons p1 and p2. In order to filter
for groups containing p1 and p2, one has to construct a QuerySet
containing p1 and p2 and then pass that into the filter call.
I think a better syntax for this would be:
Group.objects.filter(persons__contains=[p1,p2])
The second problem I hit was if I wanted to filter to get Groups which
_only_ containing p1 and p2 then I have to do something like:
Group.objects.annotate(num_persons=Count('persons')).filter(num_persons=2).filter(persons=q)
where q is the QuerySet mentioned earlier.
This would be considerably nicer:
Group.objects.filter(persons=[p1,p2])
What do people think about this? Is it worth my looking into some code
to do it?
Cheers,
Dan
--
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: Test optimizations (2-5x as fast)
Here's my proposal, assuming it can be done: 1. Create default database. 2. Run a test 3. If a test has fixtures, check for, and if not, copy base table to ``name_``. 4. Start transaction 5. Run Tests 6. Roll back I think that pretty much would solve all cases, and assuming you reuse tons of fixtures it should be a huge benefit. Also if the begin/rollback aren't good enough, and we can already "copy" a database, then we could just continually copy databases each time (assuming its fast). On May 19, 6:12 am, Hanne Moa wrote: > On 18 May 2011 01:46, Erik Rose wrote: > > >> Is there a sensible to way "copy" databases in SQL? > > > SQL 2003 introduced CREATE TABLE x LIKE y for cloning the schema of a > > table. It's supported in MySQL at least. You could then do a bunch of > > INSERT INTO ... SELECTs if you deferred foreign key checks first. > > Sometimes, in order to rescue data from an overfull table (because the > cleanup-job had died and a DELETE would take too long) I've done the > following: > > - start transcation > - rename bad table > - receate the table (CREATE TABLE x LIKE would work) > - INSERT INTO ... SELECT good data into the recreated table from the > renamed table > - drop renamed table > - end transaction > > This works even when the system is up and running, on production servers. > > HM -- 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: RFC: #12417 - Support for signing (including secure cookies)
> int(time.time()) == 1305761382 > base62.encode(1305761382) == '1QMqBS' > base62.encode(1305761382) == 'KgwVC' Oops! meant to say base62.encode(305761382) == 'KgwVC' -Paul -- 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: RFC: #12417 - Support for signing (including secure cookies)
>> Baseconv is a clever bit of work. It should probably be using our full >> base64 charset. We could also shave some digits in the time-limited >> output there by subtracting from a more recent fixed value than the >> unix epoch, the way the password reset token code does. > > The TimeStampSigner requires the seconds to correct determine whether the > signature is still valid, so I'm not sure if that's a good idea. If you > have an idea to have both thing, I'd appreciate any help. If we subtract 1e9 from our timestamp, we get a 5 digit timestamp rather than 6 for the next 19 years. If we add - and _ to our allowed characterset, we extend that to 24 years. int(time.time()) == 1305761382 base62.encode(1305761382) == '1QMqBS' base62.encode(1305761382) == 'KgwVC' Shaving 1 character seems like an overoptimization, except that we're talking about storing values in cookies, where space is already very limited. I'll see if I can find you on IRC to discuss the salting. -Paul -- 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: templates block prepend and append
This should solve my problems, therefore my question is no longer valid.
I missed that in the documentation.
Probably I should ask at django-users first.
Although
{% extends "admin/index.html" after "blockname" %}
would be a nice shorthand.
or
{% from "admin/index.html" import "blockname" %}
to import only one block from a template file.
--
Matt Harasymczuk
http://www.matt.harasymczuk.pl
--
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: templates block prepend and append
On 20/05/11 17:14, Mateusz Harasymczuk wrote:
> I have recently fought with extending templates.
> Plenty of my usecases are almost the same: append some html before or
> after admin templates blocks.
{{ block.super }} sounds like what you want. If not, please let us know why.
Regards,
Luke
--
The early bird gets the worm, but the second mouse gets the cheese.
--Steven Wright
Luke Plant || http://lukeplant.me.uk/
--
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: Reshaping the "Contributing to Django" documentation
"[...] try and duplicate it. If you can duplicate it [...]" I'd stick with "reproduce" here because "duplicate" may be confused with "duplicate tickets". -- 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.
templates block prepend and append
I have recently fought with extending templates.
Plenty of my usecases are almost the same: append some html before or after
admin templates blocks.
To do so, I have to take template, copy the contents and save modified file
as a html in my templates dir.
What happens if django contrib.admin pages gets an update?
I have to take templates and do my job once again.
I suggest adding templatetag
- {% prepend "blockname" %}{% endprepend %}
- {% append "blockname" %}{% endappend %}
or "before/after" blocks
or even modification to extends
{% extends "admin/index.html" "after" "blockname" %}
What do you think?
--
Matt Harasymczuk
http://www.matt.harasymczuk.pl
--
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: Reshaping the "Contributing to Django" documentation
On Fri, May 20, 2011 at 5:31 AM, Julien Phalip wrote:
> Hi there,
>
> I've been working on reshaping the documentation about contributing to
> Django, in particular the rather dense historical page [1] and the
> excellent recently added how-to guide [2]. This documentation has sort
> of grown organically over the years and has become a bit difficult to
> read, so I tried to improve things a bit.
>
> I've submitted a patch in the designated ticket:
> http://code.djangoproject.com/ticket/15796
Awesome!
One nitpick thought. I expect that people reporting bugs will go to
the "bugs-and-features" page, which is fine. However, as is often the
case, when their ticket is marked "accepted" (or some other triage
stage) they often get confused about what that means (as we all know).
If they are only looking to get their one ticket fixed, I doubt they
will find on there own the explanations of the various stages now
under "triaging-tickets" ("I just want my one ticket fixed. I don't
have time to work on other peoples tickets, Why would I look there?").
Perhaps a link to those explanations should be added to the
"bugs-and-features" section? Just a thought.
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
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: list_display does not allow foreign keys __ syntax
Usage would be: list_display = (ff('model__field__fkfield',
short_description='FK Field') but ideally, the short_description
should be optional with the default logic being used to fetch it out
of the FK.
We can change the __ to a . easily enough without any impact to
anything 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
> for how many different projects/use cases.
> I have overseen Django used at more than a few projects and my
> observation is that the guesswork logic that you described that is
> presently followed for the headers will work very well (~75%) for FK
> fields (i.e. take short description/verbose_name/name of field itself)
> from the final model.
> I realize that this may not be perfect and for advanced cases a
> fallback to callables would be required. its anybody guess without
> analyzing every single django project out there to say how many people
> would benefit.
>
> All in all, without this estimation maybe not worth the effort you
> described building the . syntax
>
> I have an alternate suggestion:
> Can we develop the accessor callable that you described to be able to
> access the short descrition/verbose_name etc and make it available as
> a shortcut/decorator in the admin? With that, it won't complicate code
> for the main admin, while keeping a quickie around for others??
> I have taken your example and developed it a bit (though it still
> violates DRY IMHO), but was wondering how the admin can pass in a
> parameter with the model description so that it can be traversed to
> obtain the field verbose_name/short_description parameters
>
> def ForeignFieldFunc(field_name, short_description=None,
> admin_order_field=None):
> def accessor(obj):
> val = obj
> for part in field_name.split('__'):
> val = getattr(val, part)
> return val
> if short_description:
> accessor.short_description = short_description
> else:
> accessor.__name__ = field_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, Anshuman Aggarwal wrote:
>
> > > list_display
> > > allows for callables and hence arbitrary names can be used which are
> > > similar to the syntax for foreign key fields.
> > > However, this problem exists for list_filter also: someone may define
> > > a
> > > field with the name class__field and try to use that in list_filter as
> > > a
> > > foreign key field. (i've just checked that you can indeed name a field
> > > like that)
>
> > > So we can't really be compensating for dev stupidity at the cost of
> > > functionality as we haven't done in list_filter also.
> > > Since all FKs always start with an alphabet are in the regex format
> > > (.+__.+.*), the __unicode etc cases can be easily and correctly
> > > filtered
> > > as is required to be done in list_filter.
>
> > OK, back to basics:
>
> > ModelAdmin.list_display answers this question:
>
> > 1) Given a Python object that is a Model instance, what pieces of
> > information should we display about it in the admin change list?
>
> > It answers the question in this way:
>
> > We display string representations of A) attributes of the instance,
> > which can be defined by strings and B) where that does not suffice,
> > arbitrary callables, which can be defined by strings (referring to
> > ModelAdmin attributes), or can be actual callables.
>
> > However, once you've answered that question, you've got another:
>
> > 2) Given only a ModelAdmin and/or Model class, how can we define
> > *titles* (i.e. column headers) for the pieces of information defined by
> > list_display?
>
> > The answer to this is harder, because in general we can't. However, we
> > can make some pretty good guesses that will cover 95%. These include:
>
> > A) if the piece of information is an attribute that is a field on the
> > class, use metadata from the Model field to create the title i.e.
> > Field.verbose_name.
>
> > This is a very good guess, because we can be pretty sure that the
> > attribute will correspond to the field.
>
> > B) if the attribute is '__str__', use the verbose_name of the Model
>
> > Failing this:
>
> > C) Just turn 'some_attribute' into 'Some attribute'
>
> > and then:
>
> > D) Allow complete customisation via the 'short_description'
> > functionality
>
> > Given this is what list_display is about, the suggestion of supporting
> > '__' like in list_filter is just the wrong thing, because that syntax
> > has to do with traversing model relationships. Given question (1), which
> > is the pr
Re: list_display does not allow foreign keys __ syntax
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
for how many different projects/use cases.
I have overseen Django used at more than a few projects and my
observation is that the guesswork logic that you described that is
presently followed for the headers will work very well (~75%) for FK
fields (i.e. take short description/verbose_name/name of field itself)
from the final model.
I realize that this may not be perfect and for advanced cases a
fallback to callables would be required. its anybody guess without
analyzing every single django project out there to say how many people
would benefit.
All in all, without this estimation maybe not worth the effort you
described building the . syntax
I have an alternate suggestion:
Can we develop the accessor callable that you described to be able to
access the short descrition/verbose_name etc and make it available as
a shortcut/decorator in the admin? With that, it won't complicate code
for the main admin, while keeping a quickie around for others??
I have taken your example and developed it a bit (though it still
violates DRY IMHO), but was wondering how the admin can pass in a
parameter with the model description so that it can be traversed to
obtain the field verbose_name/short_description parameters
def ForeignFieldFunc(field_name, short_description=None,
admin_order_field=None):
def accessor(obj):
val = obj
for part in field_name.split('__'):
val = getattr(val, part)
return val
if short_description:
accessor.short_description = short_description
else:
accessor.__name__ = field_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, Anshuman Aggarwal wrote:
>
>
>
>
>
> > list_display
> > allows for callables and hence arbitrary names can be used which are
> > similar to the syntax for foreign key fields.
> > However, this problem exists for list_filter also: someone may define
> > a
> > field with the name class__field and try to use that in list_filter as
> > a
> > foreign key field. (i've just checked that you can indeed name a field
> > like that)
>
> > So we can't really be compensating for dev stupidity at the cost of
> > functionality as we haven't done in list_filter also.
> > Since all FKs always start with an alphabet are in the regex format
> > (.+__.+.*), the __unicode etc cases can be easily and correctly
> > filtered
> > as is required to be done in list_filter.
>
> OK, back to basics:
>
> ModelAdmin.list_display answers this question:
>
> 1) Given a Python object that is a Model instance, what pieces of
> information should we display about it in the admin change list?
>
> It answers the question in this way:
>
> We display string representations of A) attributes of the instance,
> which can be defined by strings and B) where that does not suffice,
> arbitrary callables, which can be defined by strings (referring to
> ModelAdmin attributes), or can be actual callables.
>
> However, once you've answered that question, you've got another:
>
> 2) Given only a ModelAdmin and/or Model class, how can we define
> *titles* (i.e. column headers) for the pieces of information defined by
> list_display?
>
> The answer to this is harder, because in general we can't. However, we
> can make some pretty good guesses that will cover 95%. These include:
>
> A) if the piece of information is an attribute that is a field on the
> class, use metadata from the Model field to create the title i.e.
> Field.verbose_name.
>
> This is a very good guess, because we can be pretty sure that the
> attribute will correspond to the field.
>
> B) if the attribute is '__str__', use the verbose_name of the Model
>
> Failing this:
>
> C) Just turn 'some_attribute' into 'Some attribute'
>
> and then:
>
> D) Allow complete customisation via the 'short_description'
> functionality
>
> Given this is what list_display is about, the suggestion of supporting
> '__' like in list_filter is just the wrong thing, because that syntax
> has to do with traversing model relationships. Given question (1), which
> is the primary question, and the answer we've come up with so far, a
> much more appropriate suggestion would be to use dotted path syntax:
>
> 'some_obj.some_field'
>
> Using '__' only makes sense for answering question 2, and only for case
> 2.A, and this is the reason we end up with silly things like
> 'foostr__', which, even if we could get it work robustly, is
> extremely ugly.
>
> Then comes the question - should we support the dot syntax? This is
> sensible for answering Q1, but not for Q2, because you can't g
Reshaping the "Contributing to Django" documentation
Hi there, I've been working on reshaping the documentation about contributing to Django, in particular the rather dense historical page [1] and the excellent recently added how-to guide [2]. This documentation has sort of grown organically over the years and has become a bit difficult to read, so I tried to improve things a bit. I've submitted a patch in the designated ticket: http://code.djangoproject.com/ticket/15796 You can also browse the html output here: http://dl.dropbox.com/u/3364022/djangodoc/internals/contributing/index.html The vast majority of the content was preserved. What I've done is: - broke the content down into logical sections. - merged information about "the documentation" from [1] and [3]. - merged information about "ticket triage" from [1] and [2]. - made a few edits, clarified a few things here and there, shifted a few bits around and smoothed out the transitions. - cross-linked the various sections. - added descriptions for the recently added "type" and "severity" attributes. - added a few suggestions for ways new contributors can help. I hope that it turns this documentation into a more maintainable and extensible shape and, as a result, that it will facilitate contributions from the community. It is a big change so I thought I'd bring it up here in case you have ideas and suggestions to improve it further or differently. Any feedback is welcome. Thanks a lot! Julien [1] http://docs.djangoproject.com/en/dev/internals/contributing/ [2] http://docs.djangoproject.com/en/dev/howto/contribute/ [3] http://docs.djangoproject.com/en/dev/internals/documentation/ -- 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.
