Re: contrib/admin/validation.py
I ran into the same problem as George before. And it always hits when I try to modify my admin pages in undocumented ways. So I would also be for some changes in this area. But I think we cannot simply remove it. Most constraints make much sense and usually help avoiding problems in your admin pages. I'm also quite sure that all these validation things help Django beginners to not run into errors with messages that cannot be understand. I've not looked into the validation code yet, but I assume that the validation takes place as soon as you register your ModelAdmin with admin.site.register. Maybe its worth to introduce a parameter here to disable the sanity checks: admin.site.register(ModelAdmin, Model, validate=False) Just my 2cents. -- Servus, Gregor Müllegger 2010/9/1 George Karpenkov : > There is a file called "validation.py" which attempts to do validation > checking for the admin. > > Though I realize it might be useful for the beginners (as a basic > sanity check) quite often I find it standing in my way and being > annoying. > The reasons are: > 1) Python does not have interfaces. It relies on "duck typing". This > file attempts to check whether the class follows the interface, yet in > a very naive way. > 2) All the check_isseq calls stop you from turning attributes into > properties, which can be useful for inheritance purposes > 3) sometimes the developer does not want a particular sanity checking. > My recent problem was trying to create a widget for a many-to-many > field with a custom through table. At the moment it is completely > impossible - validation.py will just raise an error, and there is no > way to go around it (if you won't count monkey-patching django). > Without validation.py I would've been able to specify the widget in > the admin settings and just do my own POST-data processing. > > In my personal opinion this whole file needs either removal, or > sufficient relaxation of many constraints. > > Any thoughts? -- 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: contrib/admin/validation.py
On 1 September 2010 08:15, George Karpenkov wrote: > The reasons are: > 1) Python does not have interfaces. It relies on "duck typing". This > file attempts to check whether the class follows the interface, yet in > a very naive way. Why hasattr() is a naive way? Using hasattr() to check for a given protocol is very common in Python. You can provide any type of object you like as long as it "quacks" like a ModelAdmin. > 2) All the check_isseq calls stop you from turning attributes into > properties, which can be useful for inheritance purposes. The problem here is actually, that the checks are done on the *class* not the instance. If you define a property in a class, it's an instance property. To have a property on a class, you must define it in the metaclass. Some of the fields have hooks for you to override (get_readonly_fields) that are more usefull then a simple property, because you also get to know the request. > 3) sometimes the developer does not want a particular sanity checking. > My recent problem was trying to create a widget for a many-to-many > field with a custom through table. At the moment it is completely > impossible - validation.py will just raise an error, and there is no > way to go around it (if you won't count monkey-patching django). > Without validation.py I would've been able to specify the widget in > the admin settings and just do my own POST-data processing. I think overriding (_)declared_fieldsets should work, i.e add your field there - not in the class attribute. > > In my personal opinion this whole file needs either removal, or > sufficient relaxation of many constraints. > IMHO, removing this constraints would be bad. Maybe we just need more/better hooks ? -- Łukasz Rekucki -- 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: contrib/admin/validation.py
On Wed, Sep 1, 2010 at 6:41 PM, Gregor Müllegger wrote: > I ran into the same problem as George before. And it always hits when I try to > modify my admin pages in undocumented ways. So I would also be for some > changes in this area. > > But I think we cannot simply remove it. Most constraints make much sense and > usually help avoiding problems in your admin pages. I'm also quite sure that > all these validation things help Django beginners to not run into errors with > messages that cannot be understand. > > > I've not looked into the validation code yet, but I assume that the validation > takes place as soon as you register your ModelAdmin with admin.site.register. > > Maybe its worth to introduce a parameter here to disable the sanity checks: > > admin.site.register(ModelAdmin, Model, validate=False) I'm not really in favor of removing validation. The validation serves a very useful purpose for the vast majority of users, and duck typing doesn't mean you can't (or shouldn't) check that the argument that has been provided actually can quack in the appropriate way on demand. I'm also not wild about the idea of a simple flag to disable validation -- that seems like a very big hammer to use when the problem is ultimately with a couple of attributes on any given ModelAdmin. However, I can see the benefit in: * Improving the existing validation checks so that they are more tolerant of data that presented as a properties instead of attributes * Refactoring the validation code so that end-users can easily write their own validators (or overwrite existing validators) on a per-attribute basis. I haven't given much thought to what this would look like, but analogies with clean_FOO() on forms would seem appropriate. 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-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: Inline template rendering in admin shouldn't silence errors
On Wed, Sep 1, 2010 at 2:03 PM, George Karpenkov
wrote:
> Steps to reproduce:
> 1) Specify a custom admin class (say A) which mentions a custom inline
> with a custom template, say "a.html"
> 2) Write anything to "a.html" which will raise TemplateSyntaxError -
> ie "{% extends "a.html" %}
> 3) Observe the change_form for A. Note that you do not see any errors,
> but instead the whole inline does not appear at all.
>
> I find this behavior extremely confusing and annoying. Is it just a
> bug or is there any reasoning behind that?
The broad reasoning is that a partial page rendering is preferable to
a 500 error when rendering a template. This is driven by production
requirements -- the end user shouldn't ever see a 500 error.
Admittedly, this can make template debugging difficult at times. There
has been some discussion in the past about whether the TEMPLATE_DEBUG
mode should be used allow for more aggressive error reporting during
testing; however, this discussion hasn't really moved beyond the
"vague initial discussion" phase.
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-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.
SQLite support for FK constraints
Hi all, SQLite 3.6.19 from Oct 14 2009 added support for enforcing these constraints. The relevant documentation is available at http://www.sqlite.org/foreignkeys.html I've opened ticket [1]14204 with a initial patch. In short, the SQLite feature has the following particularities: * There is no need to defer the declaration for these constraints to avoid references to tables still no created because no check is performed at CREATE TABLE time. * In fact, there is no support in ALTER TABLE for adding constraints after the fact. * It supports deferring the constraint enforcement until the end of a transaction (by using 'DEFERRABLE INITIALLY DEFERRED' in the FOREIGN KEY declaration). * It has no support for DROP CONSTRAINT so if a table of a model pointed to by a FK is deleted there is no way to delete the constraint (beforehand of afterwards). This leaves us in the situation in which we can easily create constraints and instruct SQLite to enforce them but we can't remove them. As this delete-this-table functionality is currently being used exclusively for DB teardown performed by tests (DatabaseCreation.sql_destroy_model() method), I' ve chosen to use ON DELETE CASCADE option when creating the FK to avoid table deletion failures caused by referencial integrity errors because in such scenarios normally all the tables of the DB are being removed anyway As you know, during normal usage of the ORM, Django currently performs its own collection of reverse FK and cascade deletes them so the point where cascade deletion is done by SQLite should never be reached (famous last words). I'm still not totally sure this is safe. * Availability of this feature can be queried and toggled by using the 'foreign_keys' pragma. Old versions of SQLite or new versions that were compiled with the feature disabled can be detected and starting with that information, it can be turned on/off explicitly. At this point the following doubts remain: Should we: * Create another backend that defers most of its functionality to the 'sqlite3' one and only change behavior to make use (and require?) the feature in SQLite? * Extend the current backend to detect the SQLite support is available, and if so change behavior to make use of it?. This is what the current patch does. * As above and additionally provide a way to control with a backend boolean switch [2]option?. Also, can/should the default value for this option be scheduled to be changed at a future Django release and providing a migration path? Did I miss too many design considerations? Regards, -- Ramiro Morales� |� http://rmorales.net 1. http://code.djangoproject.com/ticket/14204 2. http://docs.djangoproject.com/en/1.2/ref/settings/#options -- 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.
New Release of ibm_db_django(1.0.1)
IBM_DB_DJANGO-1.0.1 --- IBM_DB_DJANGO adaptor enables access to IBM databases from Django applications http://www.djangoproject.com/. The adaptor is developed and maintained by IBM. What's New? - Fixed LIMIT constraint in select statement with column name alias - Fixed Unique column constraint with one NULL value - Fixed Unique columns together with one null value - Added Standard deviation, Variance function support (for population standard deviation and variance) - Added MOD, BITAND and BITOR function support SVN access to the source --- http://code.google.com/p/ibm-db/source/browse/trunk/IBM_DB/ibm_db_django/ Installation $ easy_install ibm_db_django Feedback/Suggestions/Issues You can provide us feedback/suggestions, or report a bug/defect, or ask for help by using any of the following channels: 1. Mailing us at open...@us.ibm.com 2. Opening a new issue at http://code.google.com/p/ibm-db/issues/list. 3. By opening new discussion at http://groups.google.co.in/group/ibm_db. For prerequisites, installation steps and help details, visit - http://code.google.com/p/ibm-db/wiki/ibm_db_django_README Try this out and let us know you valuable feedback. Have fun. Cheers, Rahul Priyadarshi Download Express-C for free, go to: --- - http://www.ibm.com/software/data/db2/express/download.html?S_CMP=ECDDWW01&S_TACT=ACDB2011 -- 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: SQLite support for FK constraints
On Wed, Sep 1, 2010 at 10:29 PM, Ramiro Morales wrote: > Hi all, > > SQLite 3.6.19 from Oct 14 2009 added support for enforcing these > constraints. The relevant documentation is available at > http://www.sqlite.org/foreignkeys.html > > I've opened ticket [1]14204 with a initial patch. > > In short, the SQLite feature has the following particularities: > > * There is no need to defer the declaration for these constraints to > avoid references to tables still no created because no check is > performed at CREATE TABLE time. > > * In fact, there is no support in ALTER TABLE for adding constraints > after the fact. > > * It supports deferring the constraint enforcement until the end of a > transaction (by using 'DEFERRABLE INITIALLY DEFERRED' in the > FOREIGN KEY declaration). > > * It has no support for DROP CONSTRAINT so if a table of a model pointed > to by a FK is deleted there is no way to delete the constraint > (beforehand of afterwards). This leaves us in the situation in which we > can easily create constraints and instruct SQLite to enforce them but > we can't remove them. > > As this delete-this-table functionality is currently being used > exclusively for DB teardown performed by tests > (DatabaseCreation.sql_destroy_model() method), I' ve chosen to use ON > DELETE CASCADE option when creating the FK to avoid table deletion > failures caused by referencial integrity errors because in such > scenarios normally all the tables of the DB are being removed anyway > As you know, during normal usage of the ORM, Django currently performs > its own collection of reverse FK and cascade deletes them so the point > where cascade deletion is done by SQLite should never be reached > (famous last words). I'm still not totally sure this is safe. > > * Availability of this feature can be queried and toggled by using the > 'foreign_keys' pragma. Old versions of SQLite or new versions that > were compiled with the feature disabled can be detected and starting > with that information, it can be turned on/off explicitly. > > At this point the following doubts remain: > > Should we: > > * Create another backend that defers most of its functionality to the > 'sqlite3' one and only change behavior to make use (and require?) > the feature in SQLite? > > * Extend the current backend to detect the SQLite support is available, > and if so change behavior to make use of it?. This is what the > current patch does. > > * As above and additionally provide a way to control with a backend > boolean switch [2]option?. Also, can/should the default value for this > option be scheduled to be changed at a future Django release and > providing a migration path? > > Did I miss too many design considerations? I'd be inclined to follow option 3. For backwards compatibility, this is something that should be disabled by default, regardless of the capabilities of the SQLite instance. DATABASES[]['OPTIONS'] can then be used to turn the feature on; if the database doesn't support the feature (i.e., pre 3.6.19), an exception would be raised. At some later version when (version >= 3.6.19) has decent market penetration, we can make a decision about whether we're going to change the default value. Given that SQLite parses but ignores REFERENCES statements (et al), I don't see any harm in always producing those statement; essentially, that makes the SQL generation comparable with all the other backends, but the database option determines whether the statements are silently parsed and ignored, or actually used. There's also going to be a need for some very clear migration instructions in the release notes, including instructions on how to add the relevant constraints to an existing database. Other than that, it sounds like you've pretty much got it covered. Great work! 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-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: Inline template rendering in admin shouldn't silence errors
Dear Russell,
I don't quite understand how an error in the admin template is
different from the error in the inline template -- why one gets
silenced and another one doesn't?
Well if I am the only person who got repeatedly hit by that
particular issue, then I guess I'll have to deal with that.
On Sep 1, 10:44 pm, Russell Keith-Magee
wrote:
> On Wed, Sep 1, 2010 at 2:03 PM, George Karpenkov
>
> wrote:
> > Steps to reproduce:
> > 1) Specify a custom admin class (say A) which mentions a custom inline
> > with a custom template, say "a.html"
> > 2) Write anything to "a.html" which will raise TemplateSyntaxError -
> > ie "{% extends "a.html" %}
> > 3) Observe the change_form for A. Note that you do not see any errors,
> > but instead the whole inline does not appear at all.
>
> > I find this behavior extremely confusing and annoying. Is it just a
> > bug or is there any reasoning behind that?
>
> The broad reasoning is that a partial page rendering is preferable to
> a 500 error when rendering a template. This is driven by production
> requirements -- the end user shouldn't ever see a 500 error.
>
> Admittedly, this can make template debugging difficult at times. There
> has been some discussion in the past about whether the TEMPLATE_DEBUG
> mode should be used allow for more aggressive error reporting during
> testing; however, this discussion hasn't really moved beyond the
> "vague initial discussion" phase.
>
> 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-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: Inline template rendering in admin shouldn't silence errors
Hi George,
I believe this is a bug since any other errors in admin (not related
to inlines) don't pass silently.
Silencing errors should always be documented, especially if error is
silenced when DEBUG is turned on.
So it's either documentation or implementation bug.
By the way, does it show 500 error page if DEBUG is on?
On Wed, Sep 1, 2010 at 1:03 PM, George Karpenkov
wrote:
> Steps to reproduce:
> 1) Specify a custom admin class (say A) which mentions a custom inline
> with a custom template, say "a.html"
> 2) Write anything to "a.html" which will raise TemplateSyntaxError -
> ie "{% extends "a.html" %}
> 3) Observe the change_form for A. Note that you do not see any errors,
> but instead the whole inline does not appear at all.
>
> I find this behavior extremely confusing and annoying. Is it just a
> bug or is there any reasoning behind that?
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
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: Inline template rendering in admin shouldn't silence errors
On Thu, Sep 2, 2010 at 1:42 PM, burc...@gmail.com wrote:
> Hi George,
>
> I believe this is a bug since any other errors in admin (not related
> to inlines) don't pass silently.
>
> Silencing errors should always be documented, especially if error is
> silenced when DEBUG is turned on.
>
> So it's either documentation or implementation bug.
IMHO, it's a documentation issue, not a bug. It all comes down to how
you interpret the operation of the {% include %} tag.
In one interpretation, you can look at at the {% include %} as a major
structural node in the template, whose role is to substitute the
contents of a subtemplate. In this case, the {% include %} doesn't
actually exist in the final template; it's just a placeholder that
gets expanded as part of the original parsing process. In this
interpretation, any syntax error in the include node would be surfaced
as a syntax error in the main parent template doing the including.
Alternatively, you can look at {% include %} as being just like any
other tag. It exists as a normal template node, and the parsed parent
template contains a node that represents the {% include %}. At
runtime, the {% include %} tag substitutes it's content; and if that
raises an error, then the rendering process swallows that error.
The second interpretation what actually happens in implementation. {%
includes %} are actual nodes in the parsed template tree. The reason
for this is that the name of the template that is rendered is actually
a variable - For example, consider the following:
{% for templ in template_list %}
{% include templ %}
{% endfor %}
The included template isn't actually loaded and resolved until time of
render. As a result, we aren't in a position to raise a
TemplateSyntaxError when we parse the original document tree. We only
parse the included template when we render the parent template with a
specific context.
For the record, this distinction is also why {% cycle %} tags don't
persist over iterated {% include %}s -- each {% include %} is an
independent rendering context, so a cycle in one include doesn't
affect subsequent iterations.
So - this is a documentation issue. However, it's a pretty subtle
point, so it's not easy to explain. If anyone wants to take a swing at
trying to explain the issue, it would certainly be a valuable
contribution to the docs, and would possibly reduce the number of
invalid bug reports that are logged against the behavior of the
include tag.
That said: if anyone has any bright ideas on how to improve error
handling when rendering templates, we're open to suggestions. However,
my original point -- that runtime template errors are considered
unacceptable -- still stands, and any suggestion needs to honor that.
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-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: Inline template rendering in admin shouldn't silence errors
Hi Russell,
I'd define
> {% for templ in template_list %}
> {% include templ %}
> {% endfor %}
as a special case, for which special command or pattern should exist.
Should it be
{% for templ in template_list %}
{% try-include template %}
{% endfor %}
or the opposite to be called
{% require template %} instead of include,
or maybe this whole pattern should be written as
{% include-first templ %}
But in most cases {% include %} is used as "require", so in my
opinion it should raise errors!
I'd also consider a require-once pattern to fix common widget chrome
problems (i.e. different parts of the page might include jquery in
headers).
On Thu, Sep 2, 2010 at 1:00 PM, Russell Keith-Magee
wrote:
> On Thu, Sep 2, 2010 at 1:42 PM, burc...@gmail.com wrote:
>> Hi George,
>>
>> I believe this is a bug since any other errors in admin (not related
>> to inlines) don't pass silently.
>>
>> Silencing errors should always be documented, especially if error is
>> silenced when DEBUG is turned on.
>>
>> So it's either documentation or implementation bug.
>
> IMHO, it's a documentation issue, not a bug. It all comes down to how
> you interpret the operation of the {% include %} tag.
>
> In one interpretation, you can look at at the {% include %} as a major
> structural node in the template, whose role is to substitute the
> contents of a subtemplate. In this case, the {% include %} doesn't
> actually exist in the final template; it's just a placeholder that
> gets expanded as part of the original parsing process. In this
> interpretation, any syntax error in the include node would be surfaced
> as a syntax error in the main parent template doing the including.
>
> Alternatively, you can look at {% include %} as being just like any
> other tag. It exists as a normal template node, and the parsed parent
> template contains a node that represents the {% include %}. At
> runtime, the {% include %} tag substitutes it's content; and if that
> raises an error, then the rendering process swallows that error.
>
> The second interpretation what actually happens in implementation. {%
> includes %} are actual nodes in the parsed template tree. The reason
> for this is that the name of the template that is rendered is actually
> a variable - For example, consider the following:
>
> {% for templ in template_list %}
> {% include templ %}
> {% endfor %}
>
> The included template isn't actually loaded and resolved until time of
> render. As a result, we aren't in a position to raise a
> TemplateSyntaxError when we parse the original document tree. We only
> parse the included template when we render the parent template with a
> specific context.
>
> For the record, this distinction is also why {% cycle %} tags don't
> persist over iterated {% include %}s -- each {% include %} is an
> independent rendering context, so a cycle in one include doesn't
> affect subsequent iterations.
>
> So - this is a documentation issue. However, it's a pretty subtle
> point, so it's not easy to explain. If anyone wants to take a swing at
> trying to explain the issue, it would certainly be a valuable
> contribution to the docs, and would possibly reduce the number of
> invalid bug reports that are logged against the behavior of the
> include tag.
>
> That said: if anyone has any bright ideas on how to improve error
> handling when rendering templates, we're open to suggestions. However,
> my original point -- that runtime template errors are considered
> unacceptable -- still stands, and any suggestion needs to honor that.
>
> 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-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.
>
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
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: Inline template rendering in admin shouldn't silence errors
On Thu, Sep 2, 2010 at 2:30 PM, burc...@gmail.com wrote:
> Hi Russell,
>
> I'd define
>> {% for templ in template_list %}
>> {% include templ %}
>> {% endfor %}
> as a special case, for which special command or pattern should exist.
>
> Should it be
> {% for templ in template_list %}
> {% try-include template %}
> {% endfor %}
> or the opposite to be called
> {% require template %} instead of include,
> or maybe this whole pattern should be written as
> {% include-first templ %}
>
> But in most cases {% include %} is used as "require", so in my
> opinion it should raise errors!
>
> I'd also consider a require-once pattern to fix common widget chrome
> problems (i.e. different parts of the page might include jquery in
> headers).
Either I'm completely missing the point you're trying to make, or
you've completely missed the point I was making.
Template rendering is a two step process:
1. Parse the template
2. Render the template.
The point I was trying to make is that at step 1, we *can't* know the
name of the subtemplate used in an {% include %}. This isn't a matter
for negotiation or something we are in a position to design -- it's
simply the way that the tag is implemented.
I don't see how changing the name of the include tag to "require" or
"try-include" changes anything, or how an alternate tag with those
names would behave differently.
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-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.
