Featurereuqest: Helpfull tracebacks

2013-08-21 Thread Roland van Laar 

Hello,

TLDR: An error message with more information to easily fix the problem.

I got this error message:
django.db.utils.DatabaseError: value too long for type character 
varying(100)


What I want is to fix this error in my code as quickly as possible.
Now I need to dig through the stacktrace,
find out which model is saved,
get the model definition,
check the CharFields for length=100 and
apply fix.

The error message is because there is a model with a CharField of length 
100.

I would like to know which Model and Field caused the error.

Such as: DatabaseError: own_app.models.User.street: value too long for 
type character varying(100).


This way, it's easier to fix this bug I had. Django comes with batteries 
included,

it should also come with helpfull error messages.
Django knows that it executes a save for a model.
Django should be able to give me this information.

I would gladly make a feature request in the issue tracker for this when 
more people

would like to have a better error message.

Regards,

Roland van Laar

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Featurereuqest: Helpfull tracebacks

2013-08-21 Thread Anssi Kääriäinen 

On 08/21/2013 12:44 PM, Roland van Laar wrote:

Hello,

TLDR: An error message with more information to easily fix the problem.

I got this error message:
django.db.utils.DatabaseError: value too long for type character
varying(100)

What I want is to fix this error in my code as quickly as possible.
Now I need to dig through the stacktrace,
find out which model is saved,
get the model definition,
check the CharFields for length=100 and
apply fix.

The error message is because there is a model with a CharField of length
100.
I would like to know which Model and Field caused the error.

Such as: DatabaseError: own_app.models.User.street: value too long for
type character varying(100).

This way, it's easier to fix this bug I had. Django comes with batteries
included,
it should also come with helpfull error messages.
Django knows that it executes a save for a model.
Django should be able to give me this information.

I would gladly make a feature request in the issue tracker for this when
more people
would like to have a better error message.
The problem is that the above error message doesn't come from Django, it 
comes from the database library. Modifying the error message to contain 
the model and field information will likely be hard. If the error 
doesn't contain the field name, then Django doesn't know the problematic 
field either.


Improvements to error messages are usually accepted. This idea, too, if 
there is a way to actually do it without ugly hacks.


 - Anssi

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Featurereuqest: Helpfull tracebacks

2013-08-21 Thread Florian Apolloner 


On Wednesday, August 21, 2013 12:18:24 PM UTC+2, Anssi Kääriäinen wrote:
>
> Improvements to error messages are usually accepted. This idea, too, if 
> there is a way to actually do it without ugly hacks. 
>

I doubt there is a way to get that from the error message itself and I'll 
strongly object to adding logic like parsing the error message to figure 
that stuff out. Especially since the traceback is pretty clear and it's not 
as if one were searching through 5000 fields in a model… Also, this error 
is the result of putting data into the database without prior validation 
which is a bad idea anyways…

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

More input on #20945

2013-08-21 Thread Curtis Maloney 
Was just after some more eyes and opinions on
https://code.djangoproject.com/ticket/20945

Current PR is at: https://github.com/django/django/pull/1490

This patch does two things:

1) it allows specifying on a {% cache %} tag which cache to use

{% cache . using="cachename" %}

2) it makes the cache tag try to use a cache called "template_fragments" if
it exists, and otherwise use "default"

This is following on from the pattern established in staticfiles, where the
CachedFilesMixin will try to use a cache called "staticfiles" if available.

So far everyone involved agrees with (1)

However, the reception of (2) has so far been... luke warm.

So I was hoping for more eyes/input on this...

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Featurereuqest: Helpfull tracebacks

2013-08-21 Thread Albert O'Connor 
On Wed, Aug 21, 2013 at 7:55 AM, Florian Apolloner wrote:

>
>
> On Wednesday, August 21, 2013 12:18:24 PM UTC+2, Anssi Kääriäinen wrote:
>>
>> Improvements to error messages are usually accepted. This idea, too, if
>> there is a way to actually do it without ugly hacks.
>>
>
> I doubt there is a way to get that from the error message itself and I'll
> strongly object to adding logic like parsing the error message to figure
> that stuff out. Especially since the traceback is pretty clear and it's not
> as if one were searching through 5000 fields in a model… Also, this error
> is the result of putting data into the database without prior validation
> which is a bad idea anyways…
>

Annoyingly it is possible to get this error after passing validation. You
can combine Postgres misconfigured not to be UTF-8 with UTF-8 strings with
multibyte characters where the validation passes because the string 100
letters or less but the database won't be able to fit the 101 bytes into
the column. It is easy to say don't misconfigure Postgres, but it can
happen even when you validate correctly.

The message is rather vague and could be more helpful, but not if it
requires hacks. You can look into the values of variables in the rather
long stacktrace to figure out what is happening.

Albert


>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
><><><>< Albert O'Connor - amjoc...@gmail.com
albertoconnor.ca | watpy.ca | go-opendata.ca

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Featurereuqest: Helpfull tracebacks

2013-08-21 Thread Michael Manfre 
Any improvements would need to be backend specific due to differences in
error messages between database servers (and potentially different versions
of the same database server).

It sounds like the identified problem is the potential for a mismatch
between model definitions and the underlying database schema. Perhaps a
better way to resolve the issue is to create a management command that
compares the model definitions against the database schemas. Part of its
check could be to identify potential issues with collation and length.

Regards,
Michael Manfre


On Wed, Aug 21, 2013 at 8:30 AM, Albert O'Connor  wrote:

>
>
>
> On Wed, Aug 21, 2013 at 7:55 AM, Florian Apolloner 
> wrote:
>
>>
>>
>> On Wednesday, August 21, 2013 12:18:24 PM UTC+2, Anssi Kääriäinen wrote:
>>>
>>> Improvements to error messages are usually accepted. This idea, too, if
>>> there is a way to actually do it without ugly hacks.
>>>
>>
>> I doubt there is a way to get that from the error message itself and I'll
>> strongly object to adding logic like parsing the error message to figure
>> that stuff out. Especially since the traceback is pretty clear and it's not
>> as if one were searching through 5000 fields in a model… Also, this error
>> is the result of putting data into the database without prior validation
>> which is a bad idea anyways…
>>
>
> Annoyingly it is possible to get this error after passing validation. You
> can combine Postgres misconfigured not to be UTF-8 with UTF-8 strings with
> multibyte characters where the validation passes because the string 100
> letters or less but the database won't be able to fit the 101 bytes into
> the column. It is easy to say don't misconfigure Postgres, but it can
> happen even when you validate correctly.
>
> The message is rather vague and could be more helpful, but not if it
> requires hacks. You can look into the values of variables in the rather
> long stacktrace to figure out what is happening.
>
> Albert
>
>
>>   --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> ><><><>< Albert O'Connor - amjoc...@gmail.com
> albertoconnor.ca | watpy.ca | go-opendata.ca
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: A diagram showing Class Based View inheritance and mixins.

2013-08-21 Thread Meshy 
Copied from the related thread on reddit:

"the folks at ccbv.co.uk have been looking to build some sort of diagram..."

We have indeed!

In fact, in response to excitement generated by this thread, I've shipped 
our best version so far. To see it: go to any class on ccbv (eg 
http://ccbv.co.uk/TodayArchiveView/) and click the "Hierarchy diagram" link 
towards the top right.

This feature is still a work in progress, and hopefully will show 
attributes/methods soon (and be better integrated into the page). For the 
moment, I hope this keeps everyone happy!

Meshy `:D`.

On Tuesday, August 20, 2013 9:56:56 AM UTC+1, George Hickman wrote:
>
> Seth,
>
> This sounds like a great idea. I believe the folks behind ccbv.co.uk are 
> also trying to do something like this, maybe you could collaborate with 
> them?
>
> George
>
> On Monday, August 19, 2013 8:40:36 PM UTC+1, Seth Moon wrote:
>>
>> Such as one for each of the pink CBVs (CreateView, UpdateView, etc)? 
>> Yeah, I'll see what I can do.
>>
>> On Monday, August 19, 2013 12:54:29 AM UTC-7, Daniel Greenfeld wrote:
>>>
>>> Seth,
>>>
>>> I like it a lot. Is there any chance you can provide a focused version 
>>> per Class-Based View?
>>>
>>> Daniel Greenfeld
>>>
>>> On Sunday, August 18, 2013 10:03:59 PM UTC+2, Seth Moon wrote:

 I believe it would be beneficial to the Django developers and users if 
 the documentation included a diagram showing the complete structure of how 
 Class Based Views get their functionality. This would be a relatively 
 simple diagram that shows the classes each generic view inherits from. The 
 reason I am proposing this is because the current state of Generic Class 
 Based Views is too complex for many people, myself included, with some 
 views inheriting from 9 other classes (CreateView, UpdateView) down a long 
 chain of both single and multiple inheritance. This would also enable 
 people to gain a deeper understanding of why the Views are structured the 
 way they are, and encourage people to explore the available BaseViews and 
 mixins in order to assemble more customized applications without having to 
 reinvent the wheel.

 I posted this on the Django Reddit 
 communitywith
  relative success being the top post. There is a 
 DIA  diagram file and SVG available 
 on a Google Drive 
 folderthat
  is publicly accessible for you to download and modify. Version 3 is 
 the most current revision and differs extensively from what I originally 
 posted on Reddit.

 A preview of the diagram can be seen below (It's a fairly large image):



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Revamping validation framework and merging django-secure once again

2013-08-21 Thread Christopher Medrela 
Progress:

- Converted `BaseCommand.verbosity` from bytestring into an unicode.

- Integrated compatibility checks.

- Deprecated "validate" command. This command delegates to "check" command 
now.
  Changed "check" command -- it performs all system checks, including model
  validation and compatibility checks.

- Added test for check of uniqueness of field combination under 
ForeignObject.

Now I'm working at rewriting admin checks (at gsoc2013-checks-admin branch 
[1]).

[1] https://github.com/chrismedrela/django/tree/gsoc2013-checks-admin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ValidationError for fields

2013-08-21 Thread Wim Feijen 
Hi Loic,

That's nice! It looks very powerful, saving lines of code and being more 
clear. 

How about:

form.add_errors(dictionary)

? Because then we can either add one or more errors at the same time.

Wim


On Wednesday, 21 August 2013 02:31:07 UTC+2, Simon Litchfield wrote:
>
> An improvement for sure. Any reason it can't be a little more pythonic, ie 
> using optional kwargs etc?
>
> My only concern is in having two ways of achieving the same thing. If the 
> latter is simpler and more flexible, does this place our entire 
> ValidationError approach to handling form and model errors in question? 
> Hmmm. Maybe we can come back to that later :-/
>
>
> On Tuesday, 20 August 2013 14:11:44 UTC+10, Loic Bistuer wrote:
>>
>> There is a ticket with a PR to address the issue of targeting specific 
>> fields when raising errors; I'm awaiting feedback on what should be the 
>> documented API. 
>>
>> https://code.djangoproject.com/ticket/20867. 
>>
>> This patch enables two patterns: 
>>
>> - Raising ValidationError({'field': 'error'}) from `Form.clean()`. 
>>
>> - Calling Form.add_errors('field', 'error') from anywhere. 
>>
>> The former is actually something that existed for a long time; only it 
>> couldn't be used from `Form.clean()`. This pattern allows targeting 
>> specific fields from the `Model` layer (see #16986). 
>>
>> The later has been proposed by @akaariai and @mjtamlyn, it's easier to 
>> use for the simple cases and it's accessible from outside the form, from a 
>> view for example. 
>>
>> The current patch only documents the dict construct for `ValidationError` 
>> since `Form.add_errors` was a private method in my original patch; should 
>> both be documented or only `Form.add_errors`? 
>>
>> -- 
>> Loic 
>>
>> On Aug 20, 2013, at 7:58 AM, Simon Litchfield  
>> wrote: 
>>
>> > Lack of clean control over field-specific form errors is an issue that 
>> has been raised and discussed many times over the years, but still the 
>> solution seems pretty inadequate. We're even directing people hack around 
>> with _errors and making excuses for it in the documentation. 
>> > 
>> https://docs.djangoproject.com/en/dev/ref/forms/validation/#form-subclasses-and-modifying-field-errors
>>  
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ValidationError for fields

2013-08-21 Thread Loic Bistuer 
On Aug 22, 2013, at 4:29 AM, Wim Feijen  wrote:

> How about:
> 
> form.add_errors(dictionary)

That's actually supported, although you need to nullify `field` explicitly: 
`form.add_errors(None, dictionary)`.

It's mostly used internally; I'm not sure it's really useful to document, since 
most likely you will need to construct that dictionary by iterating through a 
series of conditions and you could call `add_errors` each time.

I did a quick poll on IRC and it looks like the singular name 
`Form.add_error(self, field, error)` is more popular because that should be the 
most common case, although `error` will still accept all kind of constructs: 
single error, list of errors, dict of errors, simple strings and 
`ValidationError` instances.

On Aug 21, 2013, at 7:31 AM, Simon Litchfield  wrote:

> An improvement for sure. Any reason it can't be a little more pythonic, ie 
> using optional kwargs etc?

I'm not too sure what you mean, could you paste some pseudocode?

> My only concern is in having two ways of achieving the same thing. If the 
> latter is simpler and more flexible, does this place our entire 
> ValidationError approach to handling form and model errors in question? Hmmm. 
> Maybe we can come back to that later :-/

The two approaches complement each other.

By design (loose coupling) you can't access `Form._errors` through most of the 
validation process: `Field.clean()`, `Validator` or validation at the `Model` 
layer for `ModelForm`. Raising `ValidationError` is your only option here.

`Form.add_error()` is just a more elegant solution to fiddling with 
`Form._errors`. It comes in handy when you want to validate "after the fact", 
like adding errors from a view or adding errors to specific fields after their 
dedicated validation cycle is done (in other words, from `Form.clean()`). 
Raising an exception was never an option here hence why we documented all the 
shortcomings of modifying `_errors` directly.

The only overlap is  `Form.clean_()`, but even here 
`Form.add_error()` wouldn't be too practical compared to raising an exception 
since you would have to manually provide the field name.

Also, as I mentioned in a previous post, if 
https://github.com/django/django/pull/1483 pass, it will become rewarding to 
provide metadata to errors (codes, and params), and the carrier for such 
metadata is `ValidationError`. Ideally you would do 
`self.add_error('fieldname', ValidationError('message', code='code'))`; so if 
you are in `Form.clean_()` you might as well raise the exception...

-- 
Loic

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Featurereuqest: Helpfull tracebacks

2013-08-21 Thread Ben Finney 
Roland van Laar  writes:

> I would like to know which Model and Field caused the error.
>
> Such as: DatabaseError: own_app.models.User.street: value too long for
> type character varying(100).

This could be done by having Django's database interface catch the
error, and chain a new exception from that one:

try:
pgsql_cursor.execute(foo)
except pgsql.SpamException as exc:
error = DatabaseError(
"in {model_name}: {exc}".format(
exc=exc, model_name=fully_qualified_model_name))
raise error from exc

See PEP 3134 for the exception chaning syntax ‘raise foo from bar’
http://www.python.org/dev/peps/pep-3134/> which is now in Python
http://docs.python.org/3/library/exceptions.html>.

-- 
 \   “I do not believe in forgiveness as it is preached by the |
  `\church. We do not need the forgiveness of God, but of each |
_o__)other and of ourselves.” —Robert G. Ingersoll |
Ben Finney

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Featurereuqest: Helpfull tracebacks

2013-08-21 Thread Florian Apolloner 
On Thursday, August 22, 2013 6:43:39 AM UTC+2, Ben Finney wrote:
>
> This could be done by having Django's database interface catch the 
> error, and chain a new exception from that one: 
>

Knowing the model alone is imo pretty useless since that's in the traceback 
anyways; also what you suggest has to happen way up higher the chain; 
otherwise model wouldn't be known…

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.