Re: Public method for getting model field names in order of definition
On Wed, Oct 21, 2009 at 6:38 AM, David Chandek-Stark wrote: > one should (probably) use the > "attname" attribute of a field for its name rather than the "name" > attribute. Why's that? I'm using the "verbose_name" attribute of the field and capitalizing the first letter to match the admin interface's behavior. Richard -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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=.
Patch Reviewing
It was suggested in #django that I ask here about some patches I've submitted: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&reporter=~rlaager&has_patch=1&order=priority What should I be doing to help get these tickets closed, one way or another? Thanks, Richard -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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=.
Re: Public method for getting model field names in order of definition
On Sat, 2009-11-21 at 05:57 -0800, Anssi Kaariainen wrote: > If I am not completely mistaken you can use your ModelForm with > field.label and field.data to get read-only view of the model. I was trying to do something like this today and didn't have any luck. Do you have a pointer to a working sample? Richard signature.asc Description: This is a digitally signed message part
Re: Public method for getting model field names in order of definition
On Mon, 2009-11-23 at 04:56 -0800, Anssi Kaariainen wrote:
> Here is a working example.
> data = {'field1': 'Foo', 'field2': 10}
> form = Example(data=data)
Thanks for the example, but that's not a ModelForm.
Richard
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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=.
Re: Problem with history view in admin page
On Tue, 2009-11-24 at 20:54 -0800, Mario Briggs wrote: > Instead we will let users run into errors when they do a '=' compare > of a Django Text type, and then let them ponder whether they need that > column as a CLOB in the backend. Shouldn't something be changing that = into a LIKE (and escaping LIKE metacharacters in the parameter)? I don't know why a user should have .filter(object_id='1') fail, as that breaks the ORM abstraction. Maybe that's not what you're suggesting? Richard signature.asc Description: This is a digitally signed message part
Re: Ticket #8425 and USStateField (again)
On Thu, 2009-12-24 at 11:44 +0800, Russell Keith-Magee wrote: > This is completely backwards compatible as long as we keep > "STATE_CHOICES" to the same subset that exists today. Yikes, that's really restrictive. You want that list to remain static until Django 2.0? I ask because the Canadian province list includes *incorrect* abbreviations, which we discovered when trying to do a simple state/province choices form field. Richard signature.asc Description: This is a digitally signed message part
[PATCH] RawQuerySet one-liner
There's a small bug in RawQuerySet. It breaks (returns a deferred model
instance instead of a regular model instance even when the appropriate
column is SELECTed) with models that have a ForeignKey with a db_column
specified. For example:
created_by = ForeignKey('User', db_column='created_by')
Here's the fix:
--- a/django/db/models/query.py
+++ b/django/db/models/query.py
@@ -1326,7 +1326,7 @@ class RawQuerySet(object):
# Construct model instance and apply annotations
skip = set()
for field in self.model._meta.fields:
-if field.name not in model_init_kwargs.keys():
+if field.attname not in model_init_kwargs.keys():
skip.add(field.attname)
if skip:
A few lines above, model_init_kwargs is populated like this:
model_init_kwargs[self.model_fields[column]]
model_fields is a property implemented by a method, which does this:
for field in self.model._meta.fields:
name, column = field.get_attname_column()
self._model_fields[converter(column)] = name
It'd be clearer if the name variable in those two lines was changed to
attname, since that's what it is. Field.get_attname_column looks like
this:
def get_attname_column(self):
attname = self.get_attname()
column = self.db_column or attname
return attname, column
Richard
signature.asc
Description: This is a digitally signed message part
Re: Admin refactoring
On Wed, 2010-02-10 at 02:41 -0800, PauloS wrote: > If we are talking about refactoring Admin code (not only html/css > stuff), do you guys think it can be more decoupled from Django ORM? How so? > Is it possible to design some abstraction middleware to loose the bond > between admin and Django ORM? To what end? What are you trying to accomplish? Richard signature.asc Description: This is a digitally signed message part
Re: GSoC: Data importation class
On Thu, 2010-03-25 at 11:34 -0500, Malcolm Tredinnick wrote: > That's not a correct statement, since Django models can often be used to > proscribe conditions on new data that is created via the web app, yet > those conditions might not be required for the universal set of data > that already exists. For example, webapp-generated data might always > require a particular field, such as the creating user, to be filled in, > whilst machine-generated data would not require that. Don't equate > validation conditions at the model level with constraints on the data at > the storage level. In my opinion, the model validation should be the same as the storage level. Instead, I would say, "Don't equate validation conditions at the view level with constraints on the data the model level." This might be a bit off-topic for this thread, but legacy data is why I wish frameworks supported some concept of warnings in their validation code. Richard signature.asc Description: This is a digitally signed message part
Re: Issues with .only() and Meta.verbose_name{,_plural} inheritance
On Tue, 2010-04-06 at 23:33 +0300, Jerome Leclanche wrote: > The following code reproduces an issue I'm getting on prod with > verbose_name. When using .only(), the class changes, and Meta does not > get inherited. > > Trac is being even more terrible than usual, I've been trying to file > a bug for the past 15 minutes. I'd love to work on a patch, hopefully > get this fixed before 1.2 as it looks like a minor fix. Any idea? > > *- > > from django.db.models import Model, fields > > class TestModel(Model): > name = fields.CharField(max_length=64) > summary = fields.TextField() > > class Meta: > verbose_name = "fooo" > > def __unicode__(self): > return self._meta.verbose_name I ran into this as well. Use this: def __unicode__(self): opts = self._meta while opts.proxy: opts = opts.proxy_for_model._meta return opts.verbose_name Richard signature.asc Description: This is a digitally signed message part
Re: High Level Discussion about the Future of Django
On Mon, 2010-04-19 at 07:55 -0700, orokusaki wrote: > With all respect, you still haven't addressed my main concern: You > told me that it was because of backward compatibility that this simple > change couldn't be put in the trunk. It is backward compatible. If I'm > wrong, it would suffice to have a simple explanation of what it > breaks. I'd like to second this question. orokusaki suggested a couple of things in ticket #13100, but I'm seconding specifically this comment: http://code.djangoproject.com/ticket/13100#comment:8 This is a serious bug/missing feature for my company's application and I don't see an obvious problem, backwards-compatibility or otherwise, with the suggested fix. Richard orokusaki: Instead of copying-and-pasting the function before and after your change, could you generate a diff (ideally against Django SVN's HEAD)? That's a more natural format for developers to review and it makes it easier for them to commit. (For these reasons, it's the normal way to submit patches in most open source projects.) Making life easy for the core developers is a key step in getting your ticket addressed (be it with Django or another project), and it's something Russell reiterated in the video. The basic steps would be: 1) svn co http://code.djangoproject.com/svn/django/trunk/ django-trunk 2) Make the change you listed. 3) svn diff > ~/13100-full-clean-dry.diff 4) Upload 13100-full-clean-dry.diff to the ticket. I could easily do this (and will if it's necessary), but I thought it better to help you to do it. signature.asc Description: This is a digitally signed message part
Cross-field Model Validation and Ticket #13100 (Was: Re: High Level Discussion about the Future of Django)
In the end, *my* requirement is that I have *some place* to put validation code that 1) can see the whole model instance, 2) will be run from the admin interface, and 3) will return nice validation failures to the user (not throw exceptions that will give the user a 500 error and send me an email). A) Is this an unreasonable pony? If so, why? B) If not, how can I implement this such that it will get accepted? I'd like to have it in for 1.2 if possible, as the model validation interfaces are new. Once released, there will be more backwards-compatibility guarantees to maintain. On Mon, 2010-04-19 at 10:53 -0500, James Bennett wrote: > On Mon, Apr 19, 2010 at 10:16 AM, Richard Laager wrote: > > On Mon, 2010-04-19 at 07:55 -0700, orokusaki wrote: > >> With all respect, you still haven't addressed my main concern: You > >> told me that it was because of backward compatibility that this simple > >> change couldn't be put in the trunk. It is backward compatible. If I'm > >> wrong, it would suffice to have a simple explanation of what it > >> breaks. > > > > I'd like to second this question. orokusaki suggested a couple of things > > in ticket #13100, but I'm seconding specifically this comment: > > http://code.djangoproject.com/ticket/13100#comment:8 > > The difference between how ModelForm works and how Model works is > that, if you're overriding clean() on a ModelForm subclass, you don't > automatically get uniqueness validation -- you have to call up to the > parent clean(), or manually apply the uniqueness validation in your > own clean(). Thank you for this explanation. orokusaki noted in ticket #13100: "The only difference between its implementation and ModelForm?._post_clean() is the internal check it makes before running validate_unique()." So is the actual issue here that naively calling Model.full_clean() will always run Model.validate_unique(), when the existing ModelForm._post_clean() code only calls Model.validate_unique() when self._validate_unique? If so, Model.full_clean() is new in 1.2. So, could we just add a kwarg like this (or similar)? def full_clean(self, exclude=None, validate_unique=True) Then, it would be modified to only call Model.validate_unique if the validate_unique argument was True. Then, you could call Model.full_clean() from ModelForm._post_clean(), passing self._validate_unique and preserve the same behavior. Alternatively, could we add another function to Model that allows for whole-model validation but does not call Model.validate_unique() and then call that from ModelForm._post_clean() instead of calling Model.full_clean()? Of course, Model.full_clean() would have to call this new validation function as well. Richard -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Cross-field Model Validation and Ticket #13100 (Was: Re: High Level Discussion about the Future of Django)
On Mon, 2010-04-19 at 15:44 -0500, Richard Laager wrote: > In the end, *my* requirement is that I have *some place* to put > validation code that 1) can see the whole model instance, 2) will be run > from the admin interface, and 3) will return nice validation failures to > the user (not throw exceptions that will give the user a 500 error and > send me an email). It's looking like this is a case of user error. I think my Django 1.2 checkout is simply too old. As I went to build a test case with HEAD, I found it works to define clean(), as documented. Sorry for the noise. I'll come back if I find a real bug. Richard signature.asc Description: This is a digitally signed message part
Re: Django git guidelines
On Tue, 2012-05-22 at 04:18 -0700, Anssi Kääriäinen wrote: > if the patch author doesn't do the final squashing, then > she/he will not end up as the "Author" in the commit logs. This isn't an issue. Just do: git commit --author "John Doe " And if the "squash merge" workflow (which isn't something I've used) doesn't allow you to set the author, then just follow it by: git commit --amend --author "John Doe " -- Richard signature.asc Description: This is a digitally signed message part
Re: About the django-core mailing list
On Thu, 2010-09-09 at 12:30 -0500, Jacob Kaplan-Moss wrote: > 1. Security-related issues. When we receive a security report, we need > to discuss it in private. Just as a data point... I'm a committer on a widely-used open source application, and we discuss these things on a "packagers" list. As the name suggests, this list includes the package maintainers for various distros. I think they find this very useful and I know we find their input helpful. Richard signature.asc Description: This is a digitally signed message part
Re: CSV serializer?
We have a CSV view (not a serializer) that is linked from every change_list page. This allows sufficiently privileged users to dump the database table into Excel to do things not covered by our existing views. We do not allow for a CSV import, but it's been something that we've wanted. We'd be very interested in this project. On Tue, 2010-10-26 at 23:05 +0800, Russell Keith-Magee wrote: > CSV has a basic > structure (i.e., comma separated values), but doesn't have a natural > way of representing multiple datatypes I think this is the biggest challenge. Could we come up with some criteria that would have to be met for a given field type's representation? Perhaps: 1) The field has to load correctly in Excel. 2) The field has to load correctly in OpenOffice.org. 3) The field has to be human readable, except where doing so would violate #1 or #2. 4) The field should match its most common SQL representation, except where doing so would violate #1, #2, or #3. Handling foreign keys is problematic. If you just export the key, you often end up with an integer that's meaningless. If you export the related object, do you use it's __unicode__ or something else? On import, do you match the provided values to existing values in the JOIN table or can new ones be added? To be honest, I haven't looked at the JSON serializer, so I'm not sure how this is handled there. Of course, JSON would support nested objects where CSV wouldn't. > multiple values for a single field When would this matter? Is there a field type in Django that uses SQL arrays? If not, SQL has the same issue. > or differentiating NULL from empty string Neither does CharField, so why does this matter? > Even in-file > metadata (sometimes represented as the first, commented out row of a > CSV file) is the subject of inconsistency. On export, you either have it or you don't. It seems that having a header row is better than not, so include it. This meets your "useful in Excel" criteria. As far as import, it's easy to strip the first row or not, but the big question is if you want to make it *optional*. If the goal of the serializer is to import data that you've previously export, then there's no need to make it optional. If you want something more generally useful, you'll have to look at the first row and try to match the columns to field names. If they all match, then it's a header row, if they don't, it's not. Richard signature.asc Description: This is a digitally signed message part
Re: Kilobyte or Kibibite
On Wed, 2011-01-12 at 21:26 +0800, Russell Keith-Magee wrote: > Until I start seeing kibibyte being used in the New York Times, or the > prefered usage in the Chicago Manual of Style, the kibibyte is little > more to me than an intriguing expression of pedantry. Yes, the > existing usage is confusing and ambiguous. We don't fix that by > picking new and relatively unknown terminology. Django's existing practice would be considered a bug in Ubuntu: https://wiki.ubuntu.com/UnitsPolicy I realize their policy isn't binding on you as upstream, but how would you suggest they fix it? Given that the filter can't know whether the application is using it for disk, RAM, or files, I'd propose it be changed to use base-10 units to get most cases right. Richard signature.asc Description: This is a digitally signed message part
Re: Ticket #15124: BooleanField should not use False as default (unless provided)
On Thu, 2011-02-03 at 13:46 -0500, Tobias McNulty wrote: > the behavior of all fields, except for BooleanField, is to default to > the empty value supported by that field. ... > On the other hand, False is in no way an "empty value." From the point of view of the model layer, your point makes sense. However, I think the UI is the challenge. This would force every BooleanField to have a drop-down (like NullBooleanField) instead of a checkbox, at least on the /add/ forms. Richard signature.asc Description: This is a digitally signed message part
Re: Brute force attacks
On Fri, 2011-03-04 at 17:22 -0500, Shawn Milochik wrote: > the thread referred to above discusses throttling, whereas the > "recommendation" provided to us by the auditors was user lockout > requiring administrator activity (human intervention) to unlock. This *creates* a denial of service vulnerability, especially if your usernames are public. (Otherwise the attacker has to guess at them.) Richard signature.asc Description: This is a digitally signed message part
Re: Support Negative Indexing on QuerySets
On Wed, 2013-07-31 at 13:01 +0100, Simon Riggs wrote:
> 3) retrieve via DESC, apply LIMIT and then re-sort by ASC using derived table
...
> (3) would require two sorts on the data like this
>
> SELECT * FROM (rest-of-query ORDER BY ... DESC LIMIT n ) ORDER BY ... ASC
I haven't followed this thread closely, but in case this is relevant...
The MSSQL plugin (at least for old versions of SQL Server) uses*
something this already. For example, in the following scenario
(extraneous columns omitted):
In [4]: User.objects.order_by('username')[20:30]
Out[4]: Executing SQL:
SELECT *
FROM (
SELECT TOP 10 *
FROM (
SELECT TOP 30 [users].[id], [users].[username] AS OrdAlias1 FROM [users]
ORDER BY OrdAlias1 ASC
) AS [users]
ORDER BY OrdAlias1 DESC
) AS [users]
ORDER BY OrdAlias1 ASC
* I didn't test the latest version of it or Django.
--
Richard
signature.asc
Description: This is a digitally signed message part
