Re: .save_m2m() failing with multi-database error
FWIW Ben, I had the same error, but under different circumstances (your message below is the top google result for the error!). For me, the problem was caused by a custom save() method in the model not calling super().save(). Did you omit such a method in your gist.github models? On 6 September 2011 17:26, Ben Standefer wrote: > > I think I might have found an issue related > to https://code.djangoproject.com/ticket/14849. The last comment says to > please email the django-dev group if there are any questions about the > ticket, so here I am. I've done my best to provide a complete test case. > I have an Event model with property 'times', which is a ManyToManyField to an > EventTime model. https://gist.github.com/c7d8319df96f5eb22cf3 > I am processing data from a POST request with a ModelForm on Event, with a > custom field and widget: https://gist.github.com/653adb9b0ecbcc823339 The > widget takes a few POST fields and generates a set of date ranges as a list > of tuples [(, ), (, )...]. The to_python() method of > the custom field takes the date ranges and returns a list of EventTime > objects. > When I try to .save_m2m() the form (test case > here: https://gist.github.com/6da4f69ade9bc7dc5b3c) I get... > ValueError: Cannot add "": instance is on > database "default", value is on database "None" > > This looks it might be an issue with the new multi-database stuff. I could > also be misunderstanding something, but after scouring the documentation for > several hours I don't see anything implying that this wouldn't work. I > suspect the unusual thing I'm doing is creating instances of a Django model > within my field's to_python() method. Most of the existing fields use > to_python() to cast to datetime or Decimal. Is it not possible to convert > value(s) into instances of Django models? > Thanks for your help. > -Ben Standefer > -Ben > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/uVcisHlDAzkJ. > 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. -- Dr Greg Turner Director, Technical Information Architect the Interaction Consortium http://interaction.net.au Phone: +61 2 8060 1067 skype: gregturner Follow us on twitter: @theixc @gsta Be green! Read from the screen. -- 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: User.objects.active() support.
On Sep 25, 8:02 am, tWoolie wrote: > I never saw that ticket. I've been looking at it purely from the > perspective of trying to inject it into the model in my app to get > around doing expensive filtering in my template. > I see Jacob's point that saving a few chars in python is not worth it > for the cost of having to read docs to figure out what it does, but > this would be a fantastic thing to have in templates where there is no > way to specify filtering. Hello, I believe for this purpose, the Proxy models feature would be the perfect solution, please see: https://docs.djangoproject.com/en/1.3/topics/db/models/#proxy-models -- 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: API for introspecting models
(That's when somebody jumps into the conversation and feel as if he's half naked wearing dirty underwear) Hello, just FYI, I've hacked a few lines of code that I use to have a simple way to access all the fields on a model (including m2m): https://github.com/magopian/django-inspect-model I'd love to have feedback on this piece of crap^W code if you do have any use of it but feels it should be improved. The code that inspects is in https://github.com/magopian/django-inspect-model/blob/master/inspect_model/utils.py and uses the "inspect" module from the stdlib. Mathieu -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/9c5d7X8p-_IJ. 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: Revisiting proxied SSL headers
On Sat, Sep 24, 2011 at 9:28 PM, Luke Plant wrote: > > I'm happy to be proved wrong, of course. Apache is very popular, though, > so if its hard in Apache, it could be said to be hard full stop. > RequestHeader unset X-Forwarded-Protocol Not precisely what I'd call hard. >From a-business-that-uses-this-sort-of-stuff POV, we don't really mind if this is fixed in Django at all. A lot of the enterprise bits that our architecture needs (SetRemoteAddrFromForwardedFor, SSL middleware) was either missing, or crippled with no intention to fix it (SetRemoteAddrFromForwardedFor couldn't handle being behind multiple proxies and was finally dumped). It was pointed out to us that what we do is not particularly like the majority of users, so we have been maintaining our own middleware classes that updates or monkey patches the request object with the appropriate info. I suppose it is analogous to DB routers. Django doesn't provide routers to handle the common ways to scale a database, but they are simple enough to write for your specific setup. There is a simple way to add your own fixups to requests, and it works, so we don't need to burden the core or contrib with it. Cheers Tom -- 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: Revisiting proxied SSL headers
On 26/09/11 12:45, Tom Evans wrote: > On Sat, Sep 24, 2011 at 9:28 PM, Luke Plant wrote: >> >> I'm happy to be proved wrong, of course. Apache is very popular, though, >> so if its hard in Apache, it could be said to be hard full stop. >> > > RequestHeader unset X-Forwarded-Protocol > > Not precisely what I'd call hard. I am indeed happy to have been proved wrong :-) ... if slightly embarrassed... I suppose we should check that this definitely works in conjunction with mod_proxy and whichever module it is that sets X-Forwarded-Protocol/Ssl. > I suppose it is analogous to DB routers. Django doesn't provide > routers to handle the common ways to scale a database, but they are > simple enough to write for your specific setup. There is a simple way > to add your own fixups to requests, and it works, so we don't need to > burden the core or contrib with it. Given the security problems of getting HttpRequest.is_secure() wrong either way, and the common solution to this particular problem, I think it is better to have support in the core for this. Luke -- "I regret I wasn't born with opposable toes." (Calvin and Hobbes) 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.
get_field_display: Django needs a template filter to allow get_field_display for a dynamic field name
There is often a need to write model-independent Django templates. By now, the only field name-dependent attribute in Django templates is get_field_display, because the particular field names must be hardcoded for each model. What I propose is a universal filter which should provide human- readable value for a field of any type. For example, like this: {% for item in query %} {% for field in fields %} {{item|human_readable:field}} {% endfor %} {% endfor %} I'm talking about something like this, but secure against exposing _meta attributes: def human_readable(value, arg): if hasattr(value, 'get_' + str(arg) + '_display'): return getattr(value, 'get_%s_display' % arg)() elif hasattr(value, str(arg)): if callable(getattr(value, str(arg))): return getattr(value, arg)() else: return getattr(value, arg) else: try: return value[arg] except KeyError: return settings.TEMPLATE_STRING_IF_INVALID Here's the corresponding ticket: https://code.djangoproject.com/ticket/16034 Best regards, Ivan Kharlamov -- 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: Revisiting proxied SSL headers
Just my two cents worth, but I think something like this is such a 'per case basis', that it probably shouldn't be included in the core. Unless you can guarantee that all web application servers/load balancers are going to correctly handle the header out of the box (i.e. inject/strip where necessary), then there's no way this could be "securely" introduced. The reason I say per case basis, is because we've had to implement this same middleware ourselves into multiple clients, all of which had to be slightly different due to the handling of the SSL header at the load balancer. Cal On Mon, Sep 26, 2011 at 1:02 PM, Luke Plant wrote: > On 26/09/11 12:45, Tom Evans wrote: > > On Sat, Sep 24, 2011 at 9:28 PM, Luke Plant > wrote: > >> > >> I'm happy to be proved wrong, of course. Apache is very popular, though, > >> so if its hard in Apache, it could be said to be hard full stop. > >> > > > > RequestHeader unset X-Forwarded-Protocol > > > > Not precisely what I'd call hard. > > I am indeed happy to have been proved wrong :-) ... if slightly > embarrassed... > > I suppose we should check that this definitely works in conjunction with > mod_proxy and whichever module it is that sets X-Forwarded-Protocol/Ssl. > > > I suppose it is analogous to DB routers. Django doesn't provide > > routers to handle the common ways to scale a database, but they are > > simple enough to write for your specific setup. There is a simple way > > to add your own fixups to requests, and it works, so we don't need to > > burden the core or contrib with it. > > Given the security problems of getting HttpRequest.is_secure() wrong > either way, and the common solution to this particular problem, I think > it is better to have support in the core for this. > > Luke > > -- > "I regret I wasn't born with opposable toes." (Calvin and Hobbes) > > 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. > > -- 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: get_field_display: Django needs a template filter to allow get_field_display for a dynamic field name
Ivan, I completely agree that it would be useful to have something like this, as I have some up against this *exact* same problem in the past. However, when I raised it as an issue on IRC - the only response I got was "stop putting your application logic into the templates" lol. So, although I'm +1 on this, I suspect there may be others who would strongly disagree with having it as part of the core. Cal On Mon, Sep 26, 2011 at 1:01 PM, Ivan Kharlamov wrote: > > > There is often a need to write model-independent Django templates. By > now, the only field name-dependent attribute in Django templates is > get_field_display, because the particular field names must be > hardcoded for each model. > > What I propose is a universal filter which should provide human- > readable value for a field of any type. > > For example, like this: > > > >{% for item in query %} > > > >{% for field in fields %} > >{{item|human_readable:field}} > >{% endfor %} > > > >{% endfor %} > > > > I'm talking about something like this, but secure against exposing > _meta attributes: > > def human_readable(value, arg): >if hasattr(value, 'get_' + str(arg) + '_display'): >return getattr(value, 'get_%s_display' % arg)() >elif hasattr(value, str(arg)): >if callable(getattr(value, str(arg))): >return getattr(value, arg)() >else: >return getattr(value, arg) >else: >try: >return value[arg] >except KeyError: >return settings.TEMPLATE_STRING_IF_INVALID > > Here's the corresponding ticket: > https://code.djangoproject.com/ticket/16034 > > Best regards, > Ivan Kharlamov > > -- > 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. > > -- 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: Revisiting proxied SSL headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/26/2011 06:16 AM, Cal Leeming [Simplicity Media Ltd] wrote: > Unless you can guarantee that all web application servers/load balancers > are going to correctly handle the header out of the box (i.e. > inject/strip where necessary), then there's no way this could be > "securely" introduced. The proposal is not to do anything automatically or by default, but to require the user to explicitly set what header to look for, with documentation warning them that they should only do this if they know that the header is always set by their proxy. I agree with Luke and Paul that support for this should be in core - as they've discussed, the status quo is in itself a security problem. And while fixing it with a custom middleware is certainly possible, it requires monkey-patching the request.is_secure() method. Anytime we have to tell a sizable percentage of our users "you really should add this custom code to your project that monkeypatches Django core" it's a pretty strong signal that core should provide better hooks instead. > The reason I say per case basis, is because we've had to implement this > same middleware ourselves into multiple clients, all of which had to be > slightly different due to the handling of the SSL header at the load > balancer. Can you be more specific here? The only implementation differences that I can imagine would be which header is checked, and which value is expected to indicate SSL vs non-SSL. The proposed hook (currently implemented in django-secure) already accounts for this variation by requiring the user to explicitly specify the header and value that should indicate an SSL request. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6AqrMACgkQ8W4rlRKtE2dxmwCfRf+gXWLvm/Bup6r0ySJ0qVVU luMAmwd5XT98WU/kIWLhbUy8NA3aPy7K =AS+A -END PGP SIGNATURE- -- 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: Revisiting proxied SSL headers
On Mon, Sep 26, 2011 at 5:39 PM, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/26/2011 06:16 AM, Cal Leeming [Simplicity Media Ltd] wrote: > > Unless you can guarantee that all web application servers/load balancers > > are going to correctly handle the header out of the box (i.e. > > inject/strip where necessary), then there's no way this could be > > "securely" introduced. > > The proposal is not to do anything automatically or by default, but to > require the user to explicitly set what header to look for, with > documentation warning them that they should only do this if they know > that the header is always set by their proxy. > Ah - in that case (is it has to be configured by the user first, and doesn't take any assumptions) then that would be much better). I thought you meant a patch to make this "just work - out of the box". > > I agree with Luke and Paul that support for this should be in core - as > they've discussed, the status quo is in itself a security problem. And > while fixing it with a custom middleware is certainly possible, it > requires monkey-patching the request.is_secure() method. Anytime we have > to tell a sizable percentage of our users "you really should add this > custom code to your project that monkeypatches Django core" it's a > pretty strong signal that core should provide better hooks instead. > > > The reason I say per case basis, is because we've had to implement this > > same middleware ourselves into multiple clients, all of which had to be > > slightly different due to the handling of the SSL header at the load > > balancer. > > Can you be more specific here? The only implementation differences that > I can imagine would be which header is checked, and which value is > expected to indicate SSL vs non-SSL. The proposed hook (currently > implemented in django-secure) already accounts for this variation by > requiring the user to explicitly specify the header and value that > should indicate an SSL request. > Yeah - the thing you mentioned above about forcing the user to configure the exact header tackles this point. The problem I had previously, was that some load balancers don't forcibly send or strip certain SSL offloading headers (such as X-Forwarded-Proto), which could result in the user being able to trick the web application into thinking it's in HTTPS, when it's not. But this isn't an issue if it's "configured on demand". > > Carl > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk6AqrMACgkQ8W4rlRKtE2dxmwCfRf+gXWLvm/Bup6r0ySJ0qVVU > luMAmwd5XT98WU/kIWLhbUy8NA3aPy7K > =AS+A > -END PGP SIGNATURE- > > -- > 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. > > -- 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: confusing things in Trac UI (was: Design decision for #1625...)
On Sep 20, 4:16 pm, Carl Meyer wrote: > > Yeah, this is confusing in our Trac UI. The "accept" radio button at the > bottom assigns the ticket to you, it doesn't actually do anything with > the triage state. To change the ticket from DDN to Accepted you'd use > the dropdown next to "Triage Stage" up in the box above. > > I'd be in favor of just removing that "accept" radio button if it isn't > hard to do; doesn't do anything you can't do with the "reassign" option, > just gets confused with the triage state. > In a vanilla Trac install, we've (my company) always had the person assigned to the ticket hit "accepted" when he/she actually starts working on the ticket. It is used to indicate that the assigned person is actively working on the ticket. I'm not arguing it one way or another with respect to Django usage, I'm just explaining what I think the purpose of that state is in an out-of-the-box Trac install. BN -- 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: confusing things in Trac UI (was: Design decision for #1625...)
Hi, On Monday, September 26, 2011 9:06:47 PM UTC+2, Brian Neal wrote: > > I'm not arguing it one way or > another with respect to Django usage, I'm just explaining what I think > the purpose of that state is in an out-of-the-box Trac install. > Jupp, that's the state now -- sadly code.djangoproject.com uses trac for ages already and as such we do have the old workflow as described here: http://trac.edgewall.org/wiki/TracWorkflow The new work flow of trac 0.11 separates accepting from assigning; see the second image on the linked page above. We could also modify that workflow and add all our Triage states completely into this work flow (see http://trac.edgewall.org/wiki/WorkFlow/Examples for some examples of work flows). Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/oUX_tTUboE0J. 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.
prefetch_related - new feature suggestion
Hi all, I finally got fed up with the common performance problem of ending up doing O(n) DB queries when you need the (many) related objects of a list of objects, and did something about it: https://code.djangoproject.com/ticket/16937 I'm pretty sure the concept is something desirable, the problem is the implementation. It is much uglier than I'd like, but I think the current way that QuerySets/Managers/related managers interact make this inevitable. The current behaviour also makes any kind of 3rd party monkey patching solution extremely hard. For example, the related object descriptors make it pretty hard to decorate instances of the queryset with some proxy objects, because they intercept any assignment of attributes of the same name. (i.e. if you have foo.bar_set, you can't do foo.bar_set == some_precalculated_objects as a performance hack). And the way the descriptors work mean that you get new manager objects (even new manager *classes*) every time you access the property, and this really works against any kind of monkey patching. If you want to implement this outside core, and you don't want to change templates and other code, I think you'd have to create a proxy for the entire model instance, and I imagine it would be a total pain. So, given how common this performance problem is, and how hard it is to implement outside core, I think we should consider even an ugly implementation. I think it is also inevitable that it is going to involve QuerySet/related managers hacking each other's internals, or duplicating to some extent. In my implementation, I put most of the ugliness into QuerySet, and a few hooks into related managers. It might be possible to clean it up a bit. There is also a fairly nasty use of .extra() which is needed so that after we retrieve M2M related objects in bulk we know which row on the primary table they refer to. I've got tests and docs in the patch on the ticket. I would say it is more than proof-of-concept at this stage, but probably less than finished patch - I may have forgotten some cases that we need to cover. Feedback welcome! Regards, Luke -- "I spilled spot remover on my dog. Now he's gone." (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: prefetch_related - new feature suggestion
On Mon, Sep 26, 2011 at 9:50 PM, Luke Plant wrote: > Hi all, > > I finally got fed up with the common performance problem of ending up > doing O(n) DB queries when you need the (many) related objects of a list > of objects, and did something about it: > > https://code.djangoproject.com/ticket/16937 > > I'm pretty sure the concept is something desirable, the problem is the > implementation. > > It is much uglier than I'd like, but I think the current way that > QuerySets/Managers/related managers interact make this inevitable. > > The current behaviour also makes any kind of 3rd party monkey patching > solution extremely hard. For example, the related object descriptors > make it pretty hard to decorate instances of the queryset with some > proxy objects, because they intercept any assignment of attributes of > the same name. (i.e. if you have foo.bar_set, you can't do foo.bar_set > == some_precalculated_objects as a performance hack). And the way the > descriptors work mean that you get new manager objects (even new manager > *classes*) every time you access the property, and this really works > against any kind of monkey patching. > > If you want to implement this outside core, and you don't want to change > templates and other code, I think you'd have to create a proxy for the > entire model instance, and I imagine it would be a total pain. > > So, given how common this performance problem is, and how hard it is to > implement outside core, I think we should consider even an ugly > implementation. I think it is also inevitable that it is going to > involve QuerySet/related managers hacking each other's internals, or > duplicating to some extent. In my implementation, I put most of the > ugliness into QuerySet, and a few hooks into related managers. It might > be possible to clean it up a bit. > > There is also a fairly nasty use of .extra() which is needed so that > after we retrieve M2M related objects in bulk we know which row on the > primary table they refer to. > > I've got tests and docs in the patch on the ticket. I would say it is > more than proof-of-concept at this stage, but probably less than > finished patch - I may have forgotten some cases that we need to cover. > > Feedback welcome! > > Regards, > > Luke > > -- > "I spilled spot remover on my dog. Now he's gone." (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. > > I'm not a fan of this, for a few reasons, firstly: because it feels wrong for a QuerySet to execute multiple queries. This isn't a deal breaker, just something that struck my conceptually initially. Second I disagree that it's difficult to do outside of core, it's not as easy as it ought to be, but it's very possible (citation: I've done it :)). Finally (for now ;)) it doesn't feel right for something inside core to have caveats like "only works if you use .all()", there's a very good technical reason for this, but something about it is irking me the wrong way. Needs more thought by me'ly yours, Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing 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: prefetch_related - new feature suggestion
On 27/09/11 03:23, Alex Gaynor wrote: > I'm not a fan of this, for a few reasons, firstly: because it feels > wrong for a QuerySet to execute multiple queries. This isn't a deal > breaker, just something that struck my conceptually initially. Second I > disagree that it's difficult to do outside of core, it's not as easy as > it ought to be, but it's very possible (citation: I've done it :)). Would you like to share your solution? I found it pretty difficult to come up with anything that: 1) could be done on a per-query basis and 2) didn't require changes to the code that would use the QuerySet objects i.e. fully API compatible. The one avenue I didn't explore yet was proxying the entire model instance, which I'm sure would work, but could have lots of annoying corner cases with Python magic methods etc. Luke -- "I spilled spot remover on my dog. Now he's gone." (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.
We're a group of students at UC Berkeley looking to contribute to Django
Hi all, We're a a group of students at UC Berkeley taking an open source class and we've decided to contribute to Django. We looked at the bug tracker but it seems a little disorganized and some of the easier bug reports are kinda trivial. Is there any suggestions on how do we start? Thanks! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/p2sX1LUo6K0J. 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: We're a group of students at UC Berkeley looking to contribute to Django
On Mon, Sep 26, 2011 at 11:10 PM, jaminw wrote: > Hi all, > > We're a a group of students at UC Berkeley taking an open source class and > we've decided to contribute to Django. > > We looked at the bug tracker but it seems a little disorganized and some of > the easier bug reports are kinda trivial. > > Is there any suggestions on how do we start? > > Thanks! > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/p2sX1LUo6K0J. > 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. > Hi. First of all, we're glad you're looking to contribute to Django! It's true, our bug tracker has a lot of stuff in it, which is often confusing to newcomers, any ways we could improve this are welcome. There's various documentation in our repository on what the exact process for contribution is (https://docs.djangoproject.com/en/dev//internals/contributing/). The most important thing (IMO), is finding something you care about, whether that's the ORM, the template language, forms, the admin, or anything in between, working on something you find interesting, maybe something you like using in Django, or that you don't like so much, makes the process of contributing to Django significantly more awesome. Hope that answers some of your questions, Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing 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: API for introspecting models
Hello (again), seems my previous message got eaten up, so I'll try a repost : I've done a small app that I use to inspect models, it lives here: https://github.com/magopian/django-inspect-model I'm afraid this isn't rocket science, and is probably very ugly. I'm using the "inspect" module from the python stdlib. Please feel free to comment on my piece of crap^Wcode and let me know if there's anything that could help or if I need to tweak/modify anything to make it useful. Regards Mathieu -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/p5usIzkHPjAJ. 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: We're a group of students at UC Berkeley looking to contribute to Django
Great to hear you're getting involved! Some things I'd like implemented in DJango involve reducing build-setup environment and expanding project uses to the CMS markets by incorporated DJango project distribution+setup. For starters, I was thinking 3 installers (exe,rpm,deb) and a shell script (sh), but eventually building a small website around DJango for setups. Steps - Download python - Install python (set location) - Download django - Install django (set location + perhaps select db info?) - Download project (perhaps pick from list?) - Install project - Option to run project + run readme I'm currently too distracted by the actual project I want to distribute to do this on my own. If a few of you are interested though, I can give you tips+guidance to get started. :] All the best, Alec Taylor On Tue, Sep 27, 2011 at 1:10 PM, jaminw wrote: > Hi all, > We're a a group of students at UC Berkeley taking an open source class and > we've decided to contribute to Django. > We looked at the bug tracker but it seems a little disorganized and some of > the easier bug reports are kinda trivial. > Is there any suggestions on how do we start? > Thanks! > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/p2sX1LUo6K0J. > 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. > -- 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.