Re: API for introspecting models
On Fri, Sep 23, 2011 at 6:10 PM, sebastien piquemal wrote: >> So - it's one of those things that *should* be documented and >> fomalized; it's just waiting on someone with the spare time to do the >> job. > > Sounds good ! Any estimation on how big is the cleaning task ? I know > documentation task can go forever :) About as long as this piece of string that I'm holding. Oh, wait - you can't see the string? Let me hold it up for you... :-) Seriously -- I can't really answer this. It's not a completely trivial task, but it's not complex on the order of "multi-db" or "no-sql support" either. The first step really is an audit -- a rough cut at documenting everything that is there at the moment. Once we have that, we can look at how the existing API is being used, and evaluate the cleanup opportunities. Once that's done, we'll be in a much better position to evaluation how much work is involved. > And what about the extra features I suggested ? A more user-friendly > way to get all -data- fields (including m2m, excluding pointers), an > easy way to get the name of the pk field of the first parent. ... > Or did I miss some methods/properties from the _meta API ? Off the top of my head, I can't answer this. It's *possible* that there might be some way to do this, but I'd need to go digging to work out for sure, and I can't refer to the documentation to find out easily :-) However, I wouldn't be at all surprised if it isn't possible. The _meta API is mostly designed for Django's own internal needs, and Django needs to make a very clear distinction between fields and m2m's, forward and reverse fields, and so on; hence the distinctions that exist in the current API. "Iterating over all fields" doesn't make much sense from an internal perspective, because different types of fields need to be handled differently. Similarly, the "hidden" _ptr fields might not be important from a public visibility perspective, but they're very important from an internal perspective. That said, just because Django doesn't have a use for the API doesn't mean it wouldn't be useful. If you can propose a clean way to augment the _meta API to provide this sort of capability, I don't see any fundamental reason why it shoudn't be included. Yours, Russ Magee %-) -- 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: gunicorn in docs
On Sat, Sep 24, 2011 at 8:12 AM, Paul McMillan wrote: > If you write a good and comprehensive set of instructions for making > django work with gunicorn, and are willing to keep them up to date, I > see no reason we shouldn't include them. It's what I use, and has the > advantage of being very, very easy to get working. I agree with Paul that this would be a good contribution -- however, I would provide one piece of guidance. There's a fine line between documentation for how to get Django to work with Gunicorn (or any other web server for that matter), and providing documentation for Gunicorn itself. The right place for canonical Gunicorn documentation is the Gunicorn project, not Django. There is certainly room for documentation on how to get Django running under Gunicorn. However the bits in Django's documentation should be restricted to the Django-specific parts -- Django-specific settings, configuration requirements, and maybe some guidance on how Django interacts with any tuning parameters (e.g., Django uses a lot of X, but not much Y, so you'll get better performance if you configure the web server to allocate extra X at the expense of Y). If you find yourself writing explanations for every setting in Gunicorn, then you should be directing the reader to Gunicorn's documentation on those settings; and if Gunicorn doesn't have adequate documentation on those settings, then that's a contribution you should be making to Gunicorn. Yours, Russ Magee %-) -- 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: gunicorn in docs
If you write a good and comprehensive set of instructions for making django work with gunicorn, and are willing to keep them up to date, I see no reason we shouldn't include them. It's what I use, and has the advantage of being very, very easy to get working. -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.
Revisiting proxied SSL headers
About a year ago Luke Plant wontfixed ticket #14597, which requested that Django add support setting for request.is_secure based on proxy-added headers (like X-Forwarded-Protocol) when Django is served by an HTTPS proxy [1]. Luke's reasons for closing were analogous to the SetRemoteAddrFromForwardedFor header [2], which Django removed because it was unreliable, really easy to get wrong, and a security issue when configured incorrectly. More recently, we changed the way we support the X-Forwarded-Host header for security reasons [3]. Support defaults to disabled, and users who need it can turn it back on. I bring these two examples up, because they are conflicting examples of how we might handle the SSL header issue. One complicating factor for the ssl header is that there are many (4 or so) ways of specifying the same meaning (that the proxy received the request on a secure connection). CarlJM's django-secure package [4] solves this problem by requiring the user to specify which header they want, if they need support for this. Luke's concerns about the security of this setting are extremely well founded. Enabling it when it is not needed is a very serious security problem, and negates many of the benefits of using SSL. In contrast, since Django doesn't support this configuration out of the box, we have users who are losing other benefits that SSL could provide when Django assumes all requests are insecure. The most striking example of this is our CSRF protection, where we enforce much more rigorous requirements on secured connections. In light of our handling of X-Forwarded-Host (which has known security issues), I propose that we reconsider support for X-Forwarded-Protocol (and relatives). The setting should require the user to find out which header their server is using, and configure it appropriately. This is enough of a barrier to entry that users won't simply set it to "on" without thinking. Additionally, if the conversation about including a django-secure style configuration check command comes to fruition, it gives us a chance to warn users again about the dangers of needlessly enabling the setting. -Paul [1] https://code.djangoproject.com/ticket/14597 [2] https://docs.djangoproject.com/en/dev/releases/1.1/#removed-setremoteaddrfromforwardedfor-middleware [3] https://www.djangoproject.com/weblog/2011/sep/09/security-releases-issued/ [4] https://github.com/carljm/django-secure -- 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.
gunicorn in docs
Hello, After watching glyphs talk [1], do we want to add a gunicorn installation instruction to the installation docs? What is your opinion? Wim [1]: http://blip.tv/djangocon/keynote-glyph-lefkowitz-5573264 -- 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.
2011/9/23 tWoolie : > I've submitted a pull request (https://github.com/django/django/pull/ > 51) for an active() relatedmanager method on the models class. I > wanted to get some feedback from other devs about inclusion into > trunk. I've included a patch to the docs if you want more info. Hello, If I understand correctly, this is same idea as #16611. This feature was rejected by a core developer, which means it won't be added to Django. The rationale is explained in https://code.djangoproject.com/ticket/16611#comment:5 Thanks for the suggestion! -- Aymeric Augustin. -- 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.
User.objects.active() support.
I've submitted a pull request (https://github.com/django/django/pull/ 51) for an active() relatedmanager method on the models class. I wanted to get some feedback from other devs about inclusion into trunk. I've included a patch to the docs if you want more info. -- 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
> So - it's one of those things that *should* be documented and
> fomalized; it's just waiting on someone with the spare time to do the
> job.
Sounds good ! Any estimation on how big is the cleaning task ? I know
documentation task can go forever :)
And what about the extra features I suggested ? A more user-friendly
way to get all -data- fields (including m2m, excluding pointers), an
easy way to get the name of the pk field of the first parent.
This would allow the user to forget that there is some multi-table
inheritance under the hood. Most of the time - when using the models -
you just use them transparently, e.g.
class Animal(models.Model):
code = models.IntegerField(primary_key=True)
name = models.CharField(max_length=100)
class Mouse(Animal):
lab = models.CharField(max_length=100)
It is great that you can do :
>>> my_mouse.lab, my_mouse.name
('acme', 'pinky')
instead of :
>>> my_mouse.lab, my_mouse.animal_ptr.name
('acme', 'pinky')
so MTI is transparent, if you know what I mean. Thing is, there is no
equivalent when you introspect your model ... which gives extra-work
to the developer, and makes introspecting more complicated. Instead of
having :
>>> [f.name for f in Mouse._meta.fields]
['code', 'name', 'animal_ptr', 'lab']
I'd love to have something in the following (not to mention the m2m
fields)
>>> [f.name for f in Mouse._meta.get_fields(exclude_ptrs=True)] #
Or why not get_all_field_names(exclude_ptrs=False)
['code', 'name', 'lab']
Because that's all you need to know in most of the cases.
Same pb with the primary key. The only way I found to get the name of
the pk field is to do :
>>> Animal._meta.pk.name
'code'
Which with Mouse will become :
>>> Mouse._meta.pk.name
'animal_ptr'
Once again, if you want to know the name of the pk field, you would
expect (MTI being transparent from the user perspective), to get
'code' instead.
Or did I miss some methods/properties from the _meta API ?
Cheers,
Sébastien
On Sep 23, 12:10 pm, Russell Keith-Magee
wrote:
> On Fri, Sep 23, 2011 at 4:46 PM, sebastien piquemal wrote:
> > Hi all !
>
> > So this might be a stupid idea, or it might have been answered
> > before ... actually it seems so obvious to me that you have probably
> > thought of it before and rejected it !!! But let's try ...
>
> > I was wondering, why isn't there a user API for introspecting models ?
>
> > OK, there is an API, through '_meta', which is not documented (unless
> > you read the source), which is not addressed to users, and is
> > therefore likely to change, and therefore unreliable.
>
> Seehttps://code.djangoproject.com/ticket/12663
>
> _meta is in a weird limbo state. It isn't *technically* stable API,
> and it isn't documented, but it's *effectively* a stable API -- both
> because it hasn't changed in a long time, and there is lots of code in
> the wild that would break hard if we changed it.
>
> So - it's one of those things that *should* be documented and
> fomalized; it's just waiting on someone with the spare time to do the
> job.
>
> There's also a light cleanup required. There are some parts of the
> _meta api -- like get_field() -- that are completely uncontroversial,
> and would clearly be stabilized as is. However, there are also API
> entry points that are more esoteric, and in some cases, are represent
> potentially duplicated functionality in the _meta structure. What is
> needed is for a motivated someone to do an audit, cleanup, and
> documentation of the code that is there.
>
> Yours,
> Russ Magee %-)
--
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
On Fri, Sep 23, 2011 at 4:46 PM, sebastien piquemal wrote: > Hi all ! > > So this might be a stupid idea, or it might have been answered > before ... actually it seems so obvious to me that you have probably > thought of it before and rejected it !!! But let's try ... > > I was wondering, why isn't there a user API for introspecting models ? > > OK, there is an API, through '_meta', which is not documented (unless > you read the source), which is not addressed to users, and is > therefore likely to change, and therefore unreliable. See https://code.djangoproject.com/ticket/12663 _meta is in a weird limbo state. It isn't *technically* stable API, and it isn't documented, but it's *effectively* a stable API -- both because it hasn't changed in a long time, and there is lots of code in the wild that would break hard if we changed it. So - it's one of those things that *should* be documented and fomalized; it's just waiting on someone with the spare time to do the job. There's also a light cleanup required. There are some parts of the _meta api -- like get_field() -- that are completely uncontroversial, and would clearly be stabilized as is. However, there are also API entry points that are more esoteric, and in some cases, are represent potentially duplicated functionality in the _meta structure. What is needed is for a motivated someone to do an audit, cleanup, and documentation of the code that is there. Yours, Russ Magee %-) -- 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.
API for introspecting models
Hi all ! So this might be a stupid idea, or it might have been answered before ... actually it seems so obvious to me that you have probably thought of it before and rejected it !!! But let's try ... I was wondering, why isn't there a user API for introspecting models ? OK, there is an API, through '_meta', which is not documented (unless you read the source), which is not addressed to users, and is therefore likely to change, and therefore unreliable. On the other hand, there are a lot of cases where introspecting your models enables much more dryer code (ModelForm, admin, but also lots of 3rd-party applications, APIs - serialization, automatic templating, and so on). So why not helping the users to do that ? I am myself working on some serializers and I need a list of ALL the fields, (ALL as in "as seen by a user"). A lot of things are actually not straight-forward, for example : many2many handled separately (which as a user you don't really care about), MTI which messes-up everything by adding pointer fields (which as a user you don't really care about either), and hiding the real pk. So, right now introspecting models is pretty much detective work, while I think providing a simple interface for it could enable a lot of powerful things to be written. Does this make sense ? Any thoughts ? Sébastien PS : here is the code I came up with to return a dict of all fields (like I said ... detective work) : http://dpaste.com/hold/619453/ PS3 : I can totally work on that / submit a patch if some are interested -- 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.
