Re: Proposal: Forms and BoundForms
Hi Adrian
On the whole, this looks like pretty good stuff to me. A few comments
along the way; some of these ideas need not be in the v1
implementation, but I mention them anyway so that we don't roll out a
system that can't accomodate them in the future:
On 9/13/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> As an alternative, my proposal has two main classes: Form and
> BoundForm.
I'm with Jacob on having a single Form class, with the bind method
used to associate data.
All the examples you have provided only use the Form instance as a
factory for producing the BoundForm instance. Is there any other
reason that you would need an unbound Form? If so, is there any reason
that the functionality on an unbound Form() would be different to
BoundForm? Isn't an unbound form the same as a form that is bound to
nothing? In which case, why not specify the binding dictionary at time
of construction (empty, if you don't want any binding)?
> Note that this is nice and terse but comes slightly at the expense of
> efficiency, as both form.is_valid() and form.bind() perform
> validation.
Wouldn't the following:
form = ContactForm().bind(**request.POST)
# or maybe form = ContactForm(**request.POST)
if request.method == 'POST' and not form.errors()
send_email_and_redirect()
return render_to_response('email_form.html', {'form':form})
be almost equivalent to your terse version, but avoid the inefficiency
of two calls to validate? It would require 1 call to validate in the
'empty form' case, but that could be immediately shortcut as 'if not
_kwargs: return false` (and it's implicitly made by the form.bind()
call on the last line of your example, anyway).
> There are two differences here:
>
> 1. form.sendername.errors.as_url rather than
> 2. "form.sendername.as_text" rather than "form.sendername". I'm not
+1 to providing the ability to select a widget at the template level,
but -1 to requiring .as_text for the default case. Similarly -1 for
errors.as_ul. Two reasons:
1) Minimizing the migration task for existing templates
2) I can't think of a data types that doesn't have a reasonable
default widget (as evidenced by the existing Forms setup). Allowing
easy access to a non-default widget would be great, but the default
widget suffices in all existing cases, and should be easy to specify
in the field definition itself.
On this note, is there an opportunity here to handle the 'this form
field requires foo.js' issue? The admin system currently has a
mechanism for gathering JS requirements; it would be nice if something
like {{ form.includes }} would output all the javascript includes
required by the fields on the form (although there are some
interesting intersections between allowing different field renderings
and knowing which JS includes are required).
> Let's change this to be similar to model classes, like so:
+1
Some other issues that come to mind:
- Handling of related objects; in particular, select widgets for
reverse m2o/m2m relations. I presume that you are looking at using an
`authors = form.SelectField()` type arrangement for handling m2m
relations? Does this approach allow for reverse m2o/m2m fields to be
in the default form for a model? (I'm fairly certain it does, but I
thought I'd check)
t- Handling of 'inline edited' objects. I, for one, would like to see
core/edit_inline removed from the model definition; for me, this is a
form rendering issue. How do you see inline forms being handled in
this setup? I seem to recall there was talk of 'recursive forms' at
one point, rather than the data-flattening approach currently used.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
Adrian Holovaty wrote: > Similarly, how would is_valid() and errors() work? If is_valid() or > errors() get passed kwargs, does the form instance automatically > become a BoundForm? What if it's already been bound? Do the kwargs > replace any existing bound data? I think with just one Form class those methods shouldn't accept any kwargs at all. The only way to set data to a form is to call bind with kwargs, then is_valid() and errors() use the state of the Form. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Ticket #648 -- {# comment goes here #} style comments
> So - if you want your patches taken seriously, treat them seriously - > don't just write them, test them too (and not just a token test either > - REALLY test them). Especially when the testing framework is already > in place for something like template tags. I don't dispute the concept here, but it would help to have a django-testing document. I'm new to python (as are a lot of django-ers, I gather), so a hit-the-ground-running overview of the django test suite would allow me to make more meaningful contributions. There's a high barrier to entry when I have to deconstruct the test architecture before I can contribute a simple patch. If you have any recommendations of where I can look, I'm willing to learn... but I as with most developers, time is scarce. > This isn't in dispute. Adrian has decreed that #648 is rejected. It > wasn't because it was hard to implement. Check the mailing list > archives for the discussion that occurred when ticket #648 was > rejected for the reasoning behind the decision. Fair enough (though I obviously don't agree with the decision). I just saw that Adrian had made a few modifications to the ticket after it had already been closed. --Ben --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Ticket #648 -- {# comment goes here #} style comments
> So - if you want your patches taken seriously, treat them seriously - > don't just write them, test them too (and not just a token test either > - REALLY test them). Especially when the testing framework is already > in place for something like template tags. I don't dispute the concept here, but it would help to have a django-testing document. I'm new to python (as are a lot of django-ers, I gather), so a hit-the-ground-running overview of the django test suite would allow me to make more meaningful contributions. There's a high barrier to entry when I have to deconstruct the test architecture before I can contribute a simple patch. If you have any recommendations of where I can look, I'm willing to learn... but I as with most developers, time is scarce. > This isn't in dispute. Adrian has decreed that #648 is rejected. It > wasn't because it was hard to implement. Check the mailing list > archives for the discussion that occurred when ticket #648 was > rejected for the reasoning behind the decision. Fair enough (though I obviously don't agree with the decision). I just saw that Adrian had made a few modifications to the ticket after it had already been closed. --Ben --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Re: Ticket #648 -- {# comment goes here #} style comments
On 9/13/06, Hawkeye <[EMAIL PROTECTED]> wrote: > There's a high barrier to entry when I have to deconstruct the test > architecture before I can contribute a simple patch. http://www.djangoproject.com/documentation/testing/ -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Ticket #648 -- {# comment goes here #} style comments
I don't know how I missed that... still that's more a django-users guide from what I can discern... write tests for your own applications. It doesn't explain how the django-developers have constructed their test suites, and how one can build upon them. Nonetheless, having this doc helps and I'll work through it when I get a chance. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Re: Ticket #648 -- {# comment goes here #} style comments
On 9/13/06, Hawkeye <[EMAIL PROTECTED]> wrote: > It doesn't explain how the django-developers have constructed their > test suites, and how one can build upon them. Django's own tests use the same system (mostly they're doctests). -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Patches, Tests and All the Rest (was: Ticket #648 -- {# comment goes here #} style comments)
On 9/13/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > I understood the critics completely different. It's not about the > committers not keeping on top, it's that there are not enough > committers. Which is not easy to solve, as discussed before, and > probably multiple times. And, I really appreciate all your work! > In Samba, we have a code base that's larger by an order of magnitude than Django's code size (just in terms of number of lines) and only a couple more regular committers than Django. We have a large number of bugs closed weekly, but then, most of our core developers are hired to develop Samba itself. Django developers are hired to develop web sites with Django and still have to find time for Django itself. As Django continues to grow in use, we as users/developers should make the case with our employers that part of our work should be to spend a certain amount of time a week filing and fixing bugs. I realize people do this as they encounter issues, but having employer support usually means having more time for this as well. There's still the issue of those patches being applied, but as the pool of submitters grows, so can the pool of committers. I can't imagine that Adrian, Jacob, et al wouldn't be happy to have more committers, but they can't just throw commit access at folks willy-nilly. Well they could, but then you'd have PHP. ;-) (Seriously, a larger number of committers doesn't necessarily mean bugs are closed quicker. The larger then number with commit access, the larger the time spent managing code, cleaning up for releases, and other general project maintenance issues. You have to strike a balance between these competing forces, IMHO.) Cheers, deryck -- Deryck Hodgehttp://www.devurandom.org/ Web Developer, Naples News http://www.naplesnews.com/ Samba Team http://www.samba.org/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
Russell Keith-Magee wrote:
> +1 to providing the ability to select a widget at the template level,
> but -1 to requiring .as_text for the default case.
What if widgets could act as filters? I think using filter syntax for
setting the widget for a field in the template would be pretty
natural::
{{ form.field }}
draws the default widget for the field type, but if you want to use
SomeOtherWidget, you can do::
{{ form.field|SomeOtherWidget }}
The tough part would be handling things on the POST side when
SomeOtherWidget is a collection of html fields that need to be
processed into one value, or something like a tags field that renders
as comma-separated text but should be processed as a list. For that
case I think you'd have to set the widget at form definition time,
otherwise you'd have mo way to know what widget's to_python method to
call to convert the input.
JP
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Ticket #648 -- {# comment goes here #} style comments
Hawkeye wrote: > if someone else has time to > write a few tests, I'd be appreciative. I have the time! I added a new patch that includes tests: http://code.djangoproject.com/ticket/648 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Ticket #648 -- {# comment goes here #} style comments
Awesome! Thanks Will :-) Seeing the diff you made makes it a lot easier to learn how to make my own tests. Also, thanks for performing the diff from the root this time. My mistake in issuing it from within the tree. Thanks again, --Ben --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Ticket #648 -- {# comment goes here #} style comments
No problem, I did the easy part. Figuring out where the tests go was a lot easier that actually adding the new syntax to the template system, I'm sure. I just hope this helps the new syntax get added. I really think it would be an important addition to the template system. Will. On 9/13/06, Hawkeye <[EMAIL PROTECTED]> wrote: > > Awesome! Thanks Will :-) > > Seeing the diff you made makes it a lot easier to learn how to make my > own tests. > Also, thanks for performing the diff from the root this time. My > mistake in issuing it from within the tree. > > Thanks again, > --Ben > > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Ticket #648 -- {# comment goes here #} style comments
Yeah, I'm a big +1 on this. I try to comment my code as much as possible to make it possible for me to go back months later and pick up where I left off in terms of understanding and this patch will greatly beautify comments. I know in the past a core dev or two resisted adding another tag type (to avoid JSP's problems with 500 different damn tag types, I imagine), but I think the benefits of this one far outweigh the "ickyness" of adding another tag. Thanks for the patch! -Tyson On Sep 13, 2006, at 9:34 AM, Will McCutchen wrote: > > No problem, I did the easy part. Figuring out where the tests go was > a lot easier that actually adding the new syntax to the template > system, I'm sure. > > I just hope this helps the new syntax get added. I really think it > would be an important addition to the template system. > > > Will. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
RequiredIfOtherFieldsGiven validator
I noticed (after inferring it probably exists) the RequiredIfOtherFieldsGiven validator, though it is currently undocumented. The default error message is, "Please enter both fields or leave them both empty." The actual test is: def __call__(self, field_data, all_data): for field in self.other: if all_data.get(field, False) and not field_data: raise ValidationError, self.error_message Since field_data is a constant, this is equvalent to: def __call__(self, field_data, all_data): if field_data: return for field in self.other: if all_data.get(field, False): raise ValidationError, self.error_message i.e. if this field is set, then if any of the other fields are not set, it's invalid. So the error message is wrong or there's a bug. Based on the name of the validator, I think the problem is in the error message. It should be more like "Please either enter this field or leave the other ones empty." What I actually need for my app is OnlyIfOtherFieldsGiven, which in fact is what the RequiredIfOtherFieldsGiven validation error claims to be doing. The test for OnlyIfOtherFieldsGiven would be: def __call__(self, field_data, all_data): for field in self.other: if bool(all_data.get(field, False)) ^ bool(field_data): raise ValidationError, self.error_message (Yes, bitwise-exclusive-or actually will work on booleans.) If there's some interest in actually having this in Django, let me know and I'll write up a ticket with patch. -- This message has been scanned for memes and dangerous content by MindScanner, and is believed to be unclean. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
On 9/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Hence, with this new API, the above view code would be written like this:
>
> form = ContactForm()
> if request.method == 'POST' and form.is_valid(**request.POST):
> send_email_and_redirect()
> return render_to_response('email_form.html', {'form':
> form.bind(**request.POST)})
Hmm... taking some ideas from Russ Magee, what about this:
form = ContactForm()
if request.method == POST and form.bind(request.POST):
send_email_and_redirect()
return render_to_response('email_form.html', {'form':form})
Assumptions: form.bind(data) does *not* return a BoundForm. bind does
the validation and probably populates form.errors or .errors() or
whatever. bind returns True or False depending on whether validation
succeeded or not. bind does not short circuit on the first error.
Validation happens only once, in the bind call. It's not entirely
obvious that a method called bind would return a boolean depending on
the success of validation, but examples and docs should clear that up
that I think. Maybe this is being too clever to save a couple of lines
or a few milliseconds though.
Just for good measure, here's what it would look like to use a change form:
address = Address.objects.get(address_id)
form = AddressChangeForm(address)
if request.method == POST and form.bind(request.POST):
# save the object and return a redirect
return render_to_response('email_form.html', {'form':form})
You pass the original object into the form constructor. The form
values are then initialized with values from the original object. When
you call bind, it overwrites the form values with the data passed to
bind.
Let me know if this doesn't make any sense. I may have forgotten to
write down some essential assumptions.
Joseph
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: CharFields and children defaulting to emtpy string
gabor wrote: > yes, (unfortunately) it is. > > the models do not validate their input. > > you will have to use a manipulator (Name.AddManipulator) to validate > your input (and then save the object). > > making the models validation-aware is planned, but not done yet. But I am not talking about validating my input here. I just don't want input to be inserted for me. For example, non-specified IntegerField attributes don't defalut to zero. So why then do non-specified CharField attributes default to empty string? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
Joseph Kocherhans wrote:
>
> form = ContactForm()
> if request.method == POST and form.bind(request.POST):
> send_email_and_redirect()
> return render_to_response('email_form.html', {'form':form})
>
> Assumptions: form.bind(data) does *not* return a BoundForm. bind does
> the validation and probably populates form.errors or .errors() or
> whatever. bind returns True or False depending on whether validation
> succeeded or not. bind does not short circuit on the first error.
>
> Validation happens only once, in the bind call. It's not entirely
> obvious that a method called bind would return a boolean depending on
> the success of validation, but examples and docs should clear that up
> that I think. Maybe this is being too clever to save a couple of lines
> or a few milliseconds though.
(I'm not an official "dev" so I hope it's not considered inappropriate
of me to provide my feedback.)
Instead of the assumption that bind() validates, why not have an
is_valid() method that assumes binding of the Form. To me this is a
more appropriate assumption since you have to bind the form to validate
it. And it leaves some flexibility open so you can bind forms and not
yet validate -- say if you want to bind and do some other form actions
and then validate.
Example...
form = ShoppingForm()
if request.method == POST and form.is_valid(request.POST):
...
Or...
form = ShoppingForm()
if request.method == POST:
form.bind(request.POST)
if form.billing_same_as_shipping == True:
# Copy billing info to shipping
form.shipping = form.billing
if form.is_valid():
...
The access methods for "form.shipping" probably aren't appropriate, but
just making a use case for extra manipulation of form data before
validation.
-Rob
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
JP wrote:
> What if widgets could act as filters? I think using filter syntax for
> setting the widget for a field in the template would be pretty
> natural::
>
> {{ form.field }}
>
> draws the default widget for the field type, but if you want to use
> SomeOtherWidget, you can do::
>
> {{ form.field|SomeOtherWidget }}
Or how about template tags for both the default form html and for form
fields (default html or other widget):
{% form form %}
{% formfield form.field %}
{% formfield form.field widget %}
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
Joseph Kocherhans wrote: > Assumptions: form.bind(data) does *not* return a BoundForm. bind does > the validation and probably populates form.errors or .errors() or > whatever. bind returns True or False depending on whether validation > succeeded or not. bind does not short circuit on the first error. > > Validation happens only once, in the bind call. It's not entirely > obvious that a method called bind would return a boolean depending on > the success of validation, but examples and docs should clear that up > that I think. It shouldn't be called 'bind' then. Binding makes sense for the original Adrian's proposal with two kinds of forms. If we will agree on a single form populated by data then 'bind' may be called 'process_data' or something... --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Re: Proposal: Forms and BoundForms
On 9/13/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Joseph Kocherhans wrote: > > Assumptions: form.bind(data) does *not* return a BoundForm. bind does > > the validation and probably populates form.errors or .errors() or > > whatever. bind returns True or False depending on whether validation > > succeeded or not. bind does not short circuit on the first error. > > > > Validation happens only once, in the bind call. It's not entirely > > obvious that a method called bind would return a boolean depending on > > the success of validation, but examples and docs should clear that up > > that I think. > > It shouldn't be called 'bind' then. Agreed. Your suggestion of 'process_data' makes more sense in fact, I like that, but I'd shorten it to just 'process'. It would do both binding and validation. > Binding makes sense for the original > Adrian's proposal with two kinds of forms. Bind still makes sense with only one kind of form, it just works differently. Rob Husdon's recent post is a good example of why. It may be something as simple as this though: def bind(data): self.bound_data = data Joseph --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Re: Proposal: Forms and BoundForms
On 9/13/06, Rob Hudson <[EMAIL PROTECTED]> wrote: > > (I'm not an official "dev" so I hope it's not considered inappropriate > of me to provide my feedback.) It's not inappropriate at all. :) > Instead of the assumption that bind() validates, why not have an > is_valid() method that assumes binding of the Form. To me this is a > more appropriate assumption since you have to bind the form to validate > it. And it leaves some flexibility open so you can bind forms and not > yet validate -- say if you want to bind and do some other form actions > and then validate. [snip] > form = ShoppingForm() > if request.method == POST: > form.bind(request.POST) > if form.billing_same_as_shipping == True: > # Copy billing info to shipping > form.shipping = form.billing > if form.is_valid(): > ... You make a good point. I was focusing on the simplest case in my example, but we might as well spell out how more complex cases would work. I think having separate mehods - 'is_valid', 'bind', and probably 'process' as well (that does both, see my response to Ivan Sagalaev) - would be a good idea. Joseph --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: CharFields and children defaulting to emtpy string
On Sep 11, 2006, at 11:25 AM, Gary Wilson wrote: > The name field does not have blank=True or null=True set, but yet I am > able to create a new Name object using no parameters (because > CharFields and children are defaluting to empty string). Is this the > intended behavior? Yes, from the documentation: http://www.djangoproject.com/documentation/model_api/#null "Note that empty string values will always get stored as empty strings, not as NULL -- so use null=True for non-string fields such as integers, booleans and dates. Avoid using null on string-based fields such as CharField and Text Field unless you have an excellent reason. If a string-based field has null=True, that means it has two possible values for "no data":NULL, and the empty string. In most cases, it's redundant to have two possible values for "no data"; Django convention is to use the empty string, not NULL." > gabor wrote: > >> yes, (unfortunately) it is. >> >> the models do not validate their input. >> >> you will have to use a manipulator (Name.AddManipulator) to validate >> your input (and then save the object). >> >> making the models validation-aware is planned, but not done yet. >> > > But I am not talking about validating my input here. I just don't > want > input to be inserted for me. For example, non-specified IntegerField > attributes don't defalut to zero. So why then do non-specified > CharField attributes default to empty string? The reason that integers without values insert as null is because their empty_strings_allowed value is False. Most non-string fields in Django have this set to False, text fields have it set to True, in order to assert the behavior described in the documentation. To override this behavior, you need to set a default value. Note that when gabor mentioned validation, he was talking about your comment about not setting blank=True. Blank=True/False is a framework constraint, null=True/False is a database constraint. Don --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Serious problems with the way Django handles file uploads
Hello everyone. I started using Django about a week ago. I have a particular app which more or less accepts CSV files, Excel files, DBase files, and whatever else, takes the uploaded file, converts it to a tab-delimited format, and then does statistical work over it. Originally this application was written in PHP by someone else. I've since taken it and rewrote it in Rails. Rails didn't have good libraries (I had to call out to Python programs anyway), and it was slow, so I rewrote it in Python, in the Pylons web framework. As I said, about a week ago I started using Django, and I more or less directly converted this app from Pylons to Django. Pretty much all the web app itself does is display a form to upload the file, it uploads the file, and then passes if off to an outside Python library which does the conversion to tab. Once that is done, the framework (in this case a Django view function) takes control again and does the statistical work over the tab-delimited file. The code more or less for the Pylons and Django versions is identical. There are obviously small changes here and there to fit each framework, but the controller or view code has changed very little. Monday I got the entire app converted over to Django. I uploaded my first file, a DBase file, and immediately noticed that it was taking *forever*. After 24 seconds, I finally got my stats page. This same process takes 3 seconds in Pylons. Something definitely wasn't right here - my Django app was actually slower than both my Rails and the PHP app. So I started doing some tests to isolate the problem. I brought the issue up in #django on freenode IRC, and someone immediately suggested that the problem might be the dev server. Know that the dev server very well could be at fault, I took a little script and got my Django app running on the exact same Paste WSGI server that my Pylons app was running on. Again, it took 24 seconds for it to run this 6 MB file. Continuing on this testing this morning, I realized that a very good way to test out exactly where bottleneck existed was to cut out the uploading process alltogether - if the process finished very quickly on a file that was already uploaded to the local filesystem, then the problem existed within how Django's actual upload process. Sure enough, when I had the process run on an already-uploaded file, the process took 3 seconds. So uploading the file was taking 21 out of 24 seconds. Again I brough this up in the IRC chat. Someone told me that nobody was going to take my serious because I wasn't running Django the 'preferred' way, ie, on mod_python/Apache. I really didn't think this was the limiting factor, but I installed Apache and mod_python and got it all setup anyway. Again, it took 24 seconds for this file to upload and process. That was 8x as long as my Pylons app running on its dinky little WSGI Python server. At this point I was able to narrow down the issue: * it had to do with Django's upload process * it was an equal problem on any server, whether Django's dev server, the Paste server, or Apache I ran some profiling in order to narrow the problem even further. This first link is a profile of the view that displays the form. This view actual doesn't do much, as I said, it pretty much just displays the form. When the form is submitted via a POST request, it is sent to this second view (the second link). This is where the upload takes place, the processing happens, and the stats are finally displayed. http://paste.e-scribe.com/1564/ http://paste.e-scribe.com/1565/ Someone suggested that an already pending patch would fix the problem. Ticket 1484, which has been superseeded by Ticket 2070 (http://code.djangoproject.com/ticket/2070) has to do with streaming uploads. This afternoon I applied the most recent patch in Ticket 2070, and suprisingly, not only did it work, it also didn't have any effect on the upload issue. Still the same 24 seconds. I also discovered some other strange stuff. The 6 MB file which I had been uploading was a DBase file. I uploaded a 7 MB Excel file, and it took 17 seconds. I uploaded a 1 MB Excel file and it took 2 seconds. I tried to upload a 13 MB CSV file and it was at 70+ seconds and still not finished. There doesn't seem to be any common pattern between all this. The filetype really shouldn't make any difference, because as I said earlier, both my Pylons app and Django app were using the same outside library in the same way in order to conver t the file. So I'm a bit stuck here. I'd love to use Django, but I cannot have it running 3x slower than another Python framework. We do a lot of file processing here. Hopefully with all this data someone will be able to come up with some kind of idea as to what the problem might be and what solution can be applied. Thanks, jp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this grou
Re: Patches, Tests and All the Rest (was: Ticket #648 -- {# comment goes here #} style comments)
Michael Radziej wrote: > I'd appreciate if we could find a > way to state what kind of patches are interesting for the > committers and what not *before* the patch is created fully. This > is of course more important for large patches. I think this is the core of my underlying concerns of how the tickets are handled currently. To use GTD terminology, there does not seem to be distinct lines between what is in the Inbox, Someday/Maybe, Waiting and Next Actions containers. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Merquery patches
Hi, I'm working over the search-api branches, I'm trying to implement the Xapian for the database API, this is near to finish, I would like that someone see the ticket[1] (I haven't write access in svn), to later merge it into then (svn). I need that someone test the others backend (Lucene and Hype), becouse I haven't it on my machine. Thanks [1] - http://code.djangoproject.com/ticket/2707 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
On 9/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Hence, with this new API, the above view code would be written like this:
>
> form = ContactForm()
> if request.method == 'POST' and form.is_valid(**request.POST):
> send_email_and_redirect()
> return render_to_response('email_form.html', {'form':
> form.bind(**request.POST)})
>
"send_email_and_redirect()"
I want that function. Surely, this is a basic example, but it hides some of
the other issues that need to be hammered out. How do you access the
data once it's validated? How do validation aware models interact
with this BoundForm? Does the user have to set up a try, except block
when they save an object or does the form know something about the
model that allows it to validate it with the validation aware model?
Finally, how does one set the default data?
> The template would look like this:
>
> ...
Personally I think it should be like this:
{% render-form form %}
That should give you almost exactly what the Admin does. If you want
more control, then you should be able to, but for the most simple
case, this should be possible.
> 1. form.sendername.errors.as_url rather than
> form.sendername.html_error_list. This gives us some flexibility to add
> other error shortcut-display types, like JavaScript or something.
Don't we have template tags for this sort of stuff? I favor a
"to_html" for just about everything in the common case, including
error lists. Otherwise, a filter or template tag should be used, or
the object's class could be subclassed do define other functionality.
(Come to think of it: the template rendering should check for a
"to_html" or ''__html__'' function before it tries str() when it comes
across "{{ object }}")
> Let's change this to be similar to model classes, like so:
>
> class ContactForm(Form):
> sendername = TextField()
> senderemail = EmailField()
> subject = TextField(maxlength=20, blank=True)
> message = TextField()
>
+1
I also think some extra default kwargs should be available:
attributes =
label =
For instance, using the given example:
message = TextField(label='Your message',
attributes={'class':'vRichTextField'})
> One big change, other than the syntax, is that 'is_required' is
> dropped, in favor of 'blank', to match our model syntax. Also, as in
> models, blank=False will be default. Currently in manipulators,
> is_required=False is default.
This is backwards to me. "is_required" is much more descriptive;
"blank" seems to say "this field is blank". I agree that it should
match up with the model, but I posit that the model syntax should
change. New users constantly ask about this in the chat-room; they
don't see a difference between "blank" and "null" in the model syntax.
I prefer "required", which is easier to understand, and is part of
the common web parlance: "required fields are marked in red". I don't
care whether it's default or not, although I would suggest polling
many real-world cases to find the most common option.
>
> Another big change is that each of the Fields in this ContactForm
> would be responsible primarily for *validation* rather than specifying
> the HTML form field. This decouples the concept of validation from the
> HTML form type.
>
I don't understand this, and I think might hold the key to a greater
understanding of your plans, could you explain how validation would
work exactly? Also, I agree with limodou that there should be a
general "validate" function that allows the writer of the Form to
provide some custom validation on the form as a whole. Likewise there
should be a "convert" function that does the same but for conversion
from HTML-POST data to Python data.
> Another thing to note: In the current Manipulator framework, sometimes
> it is convenient to be able to construct self.fields dynamically. We
> should provide a way to do that with the new syntax.
+1
> So that's the proposal -- thoughts/criticisms? I'd like to get this
> out there as soon as possible, because we (or, rather, I) have dawdled
> for quite some time!
Some things occur to me:
The whole BoundForm and Form thing is really crufty. When does the
Form NOT have data associated with it? And when would you really want
to have it validate data but not "bind" that data?
There needs to be a fundemental change in the model syntax as well,
which I'm sure you don't want to hear, but it's true. Half
(hyperbolishly) of the stuff that is in the model syntax is really
there to define the Form. You have this sort of siamease twin, but
I'm not sure if it should be ripped apart or reinforced to support the
whole DRY / in-one-place paradigm.
Defining a Form, should be like defining a Model-Manager, it should be
portable in the way that many applications can utilize it, including
the one the Model was written for AND the Admin. That is why I favor
a "Manipulator" approach which would not only define fields, but also
define what to do with t
Re: Proposal: Forms and BoundForms
On 14/09/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
>
> On 9/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> >
> > Hence, with this new API, the above view code would be written like this:
> >
> > form = ContactForm()
> > if request.method == 'POST' and form.is_valid(**request.POST):
> > send_email_and_redirect()
> > return render_to_response('email_form.html', {'form':
> > form.bind(**request.POST)})
> >
>
> "send_email_and_redirect()"
> I want that function. Surely, this is a basic example, but it hides some of
> the other issues that need to be hammered out. How do you access the
> data once it's validated? How do validation aware models interact
> with this BoundForm? Does the user have to set up a try, except block
> when they save an object or does the form know something about the
> model that allows it to validate it with the validation aware model?
> Finally, how does one set the default data?
>
> > The template would look like this:
> >
> > ...
>
> Personally I think it should be like this:
>
> {% render-form form %}
>
>
> That should give you almost exactly what the Admin does. If you want
> more control, then you should be able to, but for the most simple
> case, this should be possible.
>
> > 1. form.sendername.errors.as_url rather than
> > form.sendername.html_error_list. This gives us some flexibility to add
> > other error shortcut-display types, like JavaScript or something.
>
> Don't we have template tags for this sort of stuff? I favor a
> "to_html" for just about everything in the common case, including
> error lists. Otherwise, a filter or template tag should be used, or
> the object's class could be subclassed do define other functionality.
> (Come to think of it: the template rendering should check for a
> "to_html" or ''__html__'' function before it tries str() when it comes
> across "{{ object }}")
>
> > Let's change this to be similar to model classes, like so:
> >
> > class ContactForm(Form):
> > sendername = TextField()
> > senderemail = EmailField()
> > subject = TextField(maxlength=20, blank=True)
> > message = TextField()
> >
>
> +1
>
> I also think some extra default kwargs should be available:
>attributes = the rendererd tag>
>label =
>
> For instance, using the given example:
>message = TextField(label='Your message',
> attributes={'class':'vRichTextField'})
>
+1 on this for me. I'd love to be able to do:
author = SelectField(attributes={'dojoType': 'Select'})
> > One big change, other than the syntax, is that 'is_required' is
> > dropped, in favor of 'blank', to match our model syntax. Also, as in
> > models, blank=False will be default. Currently in manipulators,
> > is_required=False is default.
>
> This is backwards to me. "is_required" is much more descriptive;
> "blank" seems to say "this field is blank". I agree that it should
> match up with the model, but I posit that the model syntax should
> change. New users constantly ask about this in the chat-room; they
> don't see a difference between "blank" and "null" in the model syntax.
> I prefer "required", which is easier to understand, and is part of
> the common web parlance: "required fields are marked in red". I don't
> care whether it's default or not, although I would suggest polling
> many real-world cases to find the most common option.
>
> >
> > Another big change is that each of the Fields in this ContactForm
> > would be responsible primarily for *validation* rather than specifying
> > the HTML form field. This decouples the concept of validation from the
> > HTML form type.
> >
>
> I don't understand this, and I think might hold the key to a greater
> understanding of your plans, could you explain how validation would
> work exactly? Also, I agree with limodou that there should be a
> general "validate" function that allows the writer of the Form to
> provide some custom validation on the form as a whole. Likewise there
> should be a "convert" function that does the same but for conversion
> from HTML-POST data to Python data.
>
> > Another thing to note: In the current Manipulator framework, sometimes
> > it is convenient to be able to construct self.fields dynamically. We
> > should provide a way to do that with the new syntax.
>
> +1
>
> > So that's the proposal -- thoughts/criticisms? I'd like to get this
> > out there as soon as possible, because we (or, rather, I) have dawdled
> > for quite some time!
>
> Some things occur to me:
>
> The whole BoundForm and Form thing is really crufty. When does the
> Form NOT have data associated with it? And when would you really want
> to have it validate data but not "bind" that data?
>
> There needs to be a fundemental change in the model syntax as well,
> which I'm sure you don't want to hear, but it's true. Half
> (hyperbolishly) of the stuff that is in the model syntax is really
> there to define the Form. You have this sort of siamease twin, but
> I'm not sure if
Re: Patches, Tests and All the Rest (was: Ticket #648 -- {# comment goes here #} style comments)
On 9/14/06, SmileyChris <[EMAIL PROTECTED]> wrote: > > Michael Radziej wrote: > > I'd appreciate if we could find a > > way to state what kind of patches are interesting for the > > committers and what not *before* the patch is created fully. This > > is of course more important for large patches. > > I think this is the core of my underlying concerns of how the tickets > are handled currently. To use GTD terminology, there does not seem to > be distinct lines between what is in the Inbox, Someday/Maybe, Waiting > and Next Actions containers. I agree with this. The general workflow and responsibility for tickets in the system is a little vague. This situation isn't helped by the fact that anyone (even anonymous users) can modify the state of patches. I think Malcolms idea of a triage team has a lot of merit, and this is exactly the kind of task that I think the triage team should be handling. Most of all, I think we need someone to explicity take ownership of the ticket system; at the moment, issue tracking is being treated very much as a community activity (since anyone can modify any ticket). While ticket reporting should be open to everyone, I don't believe that effective ticket management can be acheived in a free-for-all framework. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Ticket #648 -- {# comment goes here #} style comments
Back on topic, check out my alternative that I thought may appease the Django gods if they are so outraged by adding another tag type. http://code.djangoproject.com/ticket/2721 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Patches, Tests and All the Rest (was: Ticket #648 -- {# comment goes here #} style comments)
On 9/13/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Russell Keith-Magee wrote: > > Submitting a patch without tests is almost _exactly_ the _worst_ thing > > you can do if you want your patch to be committed. > > When I submit a patch, I'd really like to see some serious > interest from the committers before I go through the loops and > create test cases, documentation and polish everything up nicely, My point is that test cases and documentation shouldn't be regarded as a post facto activity; they are a core part of develoment itself. If you're going to devote time to working on a problem, you should work on the whole problem, not just the fun part. However, that said, I agree that nobody wants to waste effort on a patch+tests+docs that will be discarded or ignored - so the problem becomes 'how do we indicate on the ticket system that a patch is required?' I agree that this is an area where the ticket system needs clarification, and the triage team could be a lot of help. > I really could not see any connection between patch quality (== > test cases, docs, follows style) and how fast it was handled. Obviously, simple changes are no brainers. However, if a patch is a deep change, I (as a developer) need to be convinced: 1) That the problem actually exists 2) That the proposed fix is the right approach to solve the problem (e.g., there are lots of patches for Manipulators at the moment - but the right fix is to get rid of them altogether) 3) That the proposed fix is correct Submitting a big, deep patch (even if it is tested) is a very small part of this - the dialog that surrounds the patch is equally important. This means a clear statement of the problem in the ticket itself, and evidence of some discussion of alternatives that has engaged the committers. Again, this is an area where a triage team could be a lot of help - checking big patches, kick-starting discussion for tickets that are worthy of deeper examination, etc. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: CharFields and children defaulting to emtpy string
Don Arbow wrote: > Yes, from the documentation: > > http://www.djangoproject.com/documentation/model_api/#null > > "Note that empty string values will always get stored as empty > strings, not as NULL -- so use null=True for non-string fields such > as integers, booleans and dates. > > Avoid using null on string-based fields such as CharField and Text > Field unless you have an excellent reason. If a string-based field > has null=True, that means it has two possible values for "no > data":NULL, and the empty string. In most cases, it's redundant to > have two possible values for "no data"; Django convention is to use > the empty string, not NULL." Ok, after some trial and error, I see that if you have null=True on a CharField, it will use NULL instead of empty string. This is what I needed because in my model I have a field that I want to be optional but unique. This is not possible if you don't put null=True for the field because Django will try to use empty string by default. Out of curiosity, any one know for what reason using empty strings for CharFields is the Django convention? Technically, isn't an empty string still data? Isn't it a bit confusing that some fields get default values and others do not? Explicit better than implicit? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
Brantley Harris wrote: > > Another thing to note: In the current Manipulator framework, sometimes > > it is convenient to be able to construct self.fields dynamically. We > > should provide a way to do that with the new syntax. > > +1 +1 Being able to contruct fields dynamically would be great. So if I had a model that stored contacts, for example, it would be nice be able to easily create a form that accepted 3 contacts, or a form that accepted 6 contacts, or a form that shows fields for 6 contacts but only requires 3 to be filled in. This would be similar to the edit_inline and num_in_admin stuff in the admin app. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
On 9/14/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
>
> On 14/09/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
> > For instance, using the given example:
> >message = TextField(label='Your message',
> > attributes={'class':'vRichTextField'})
> >
>
> +1 on this for me. I'd love to be able to do:
>
> author = SelectField(attributes={'dojoType': 'Select'})
Agreed on the need, not on the implementation.
My understanding is that idea of the .as_text, etc, modifiers on
FormFields is to allow a FormField to be represented in different ways
on a page; to me, putting attributes in the field definition implies
that every renderer (as_text, as_select, etc), should use that
attribute.
IMHO, a better approach would be to allow rendering extensions to be
registered on the field itself; e.g.,
author = SelectField(extra_renderers={'dojo':dojo_renderer,
'brantley':brantley_renderer})
The goal being to allow:
- {{ form.author }} to render as a the default widget, without dojo or
class modifications
- {{ form.author.as_dojo }} to render as a 'dojo-ified' widget
- {{ form.author.as_brantley }} renders with a modified 'class' attribute
The onus is then on the underlying as_text/as_select etc
implementations to allow easy modification/extension of attributes;
e.g.,
class SelectField:
...
def as_select(self, **kwargs):
_class = kwargs.getdefault('class','vSelectMultiple')
return "...' % _class
def brantley_renderer(self):
return self.as_select(class='vBrantleyClass')
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: CharFields and children defaulting to emtpy string
On Thu, 2006-09-14 at 02:09 +, Gary Wilson wrote: > Out of curiosity, any one know for what reason using empty strings for > CharFields is the Django convention? Technically, isn't an empty > string still data? Isn't it a bit confusing that some fields get > default values and others do not? Explicit better than implicit? > Well, storing NULL vs Empty-string should consume just about the same amount of data or the difference should be insignificant. However, I think it empty-string was used due to the variations in how databases handle NULL values in strings and how to handle the strings ['NULL','Null','nul'] not sure if I read that somewhere or came up with it on my own though. :) /Marc DM --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: schema-evolution: status?
Derek,
I have manually merged the trunk into my local working copy of the
schema-evolution branch and started playing with it. I wanted to
question the SQL "sqlevolve" is outputting. I have this model in an
application called "asset":
class Interface(models.Model):
name = models.CharField(maxlength=64, core=True, db_index=True,
help_text='The name of the interface as given by the asset.')
interfacetype = models.ForeignKey(InterfaceType)
ipaddress = models.ForeignKey(IPAddress, verbose_name='IP Address',
raw_id_admin=True)
# allow for EUI-48 and EUI-64 addresses
mac_address = models.CharField(maxlength=24, blank=True,
help_text='The EUI-48 or EUI-64 physical address of the interface.')
domain = models.CharField(maxlength=255, blank=True,
help_text='The DNS domain this host resides in.')
asset = models.ForeignKey(Asset, edit_inline=models.TABULAR,
num_in_admin=10, num_extra_on_change=5)
objects = InterfaceManager()
def _get_meta(self):
return self._meta
meta = property(_get_meta)
def __str__(self):
return "%s:%s" % (self.asset, self.name)
def get_absolute_url(self):
return self.asset.get_absolute_url()
class Meta:
ordering = ['name']
unique_together = (('asset', 'name'),)
class Admin:
pass
and the schema from "./manage.py sql asset":
CREATE TABLE "asset_interface" (
"id" serial NOT NULL PRIMARY KEY,
"name" varchar(64) NOT NULL,
"interfacetype_id" integer NOT NULL,
"ipaddress_id" integer NOT NULL REFERENCES "ip_ipaddress" ("id"),
"mac_address" varchar(24) NOT NULL,
"domain" varchar(255) NOT NULL,
"asset_id" integer NOT NULL REFERENCES "asset_asset" ("id"),
UNIQUE ("asset_id", "name")
);
when I run "./manage.py sqlevolve asset" with absolutely no changes to
my models it outputs:
BEGIN;
ALTER TABLE "asset_interface" ADD COLUMN "name_tmp" varchar(64);
UPDATE "asset_interface" SET "name_tmp" = "name";
ALTER TABLE "asset_interface" DROP COLUMN "name";
ALTER TABLE "asset_interface" RENAME COLUMN "name_tmp" TO "name";
ALTER TABLE "asset_interface" ALTER COLUMN "name" SET NOT NULL;
COMMIT;
Any ideas why it is doing this?
regards
matthew
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
OT : Django Trac crashes Safari
Occasionally, simply mousing over a link on the Trac search results page causes Safari to crash. Here is the ticket and the changeset that provides a javascript fix. The fix looks fairly benign (I guess Safari doesn't like the splitText () function). http://trac.edgewall.org/ticket/3451 http://trac.edgewall.org/changeset/3455 Should I post a ticket to request this fix, even though it's infrastructure related? I can't find the version that djangoproject is using, the changeset mentions 0.9.6, with a final fix in 0.10. Don --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: CharFields and children defaulting to emtpy string
On Sep 13, 2006, at 7:09 PM, Gary Wilson wrote: > > Out of curiosity, any one know for what reason using empty strings for > CharFields is the Django convention? Technically, isn't an empty > string still data? Isn't it a bit confusing that some fields get > default values and others do not? Explicit better than implicit? My guess is that you need less code when you can assume that all text columns in the database contain strings. Python strings are first- class objects and so have instance methods you can call by appending the function call onto the variable. If you had nulls returned from those text columns, then every time you wanted to execute a string function, you'd have to test for None, then convert it. Then with a test, you may waste code AND cycles because if you code if not string: string = '' string.split(...) half the time you may be assigning an empty string to a variable that already contains an empty string. That's one reason I can think of, there may be others. Don --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: schema-evolution: status?
which backend are you using?
Matthew Flanagan wrote:
> Derek,
>
> I have manually merged the trunk into my local working copy of the
> schema-evolution branch and started playing with it. I wanted to
> question the SQL "sqlevolve" is outputting. I have this model in an
> application called "asset":
>
> class Interface(models.Model):
> name = models.CharField(maxlength=64, core=True, db_index=True,
> help_text='The name of the interface as given by the asset.')
> interfacetype = models.ForeignKey(InterfaceType)
> ipaddress = models.ForeignKey(IPAddress, verbose_name='IP Address',
> raw_id_admin=True)
> # allow for EUI-48 and EUI-64 addresses
> mac_address = models.CharField(maxlength=24, blank=True,
> help_text='The EUI-48 or EUI-64 physical address of the interface.')
> domain = models.CharField(maxlength=255, blank=True,
> help_text='The DNS domain this host resides in.')
> asset = models.ForeignKey(Asset, edit_inline=models.TABULAR,
> num_in_admin=10, num_extra_on_change=5)
> objects = InterfaceManager()
>
> def _get_meta(self):
> return self._meta
> meta = property(_get_meta)
>
> def __str__(self):
> return "%s:%s" % (self.asset, self.name)
>
> def get_absolute_url(self):
> return self.asset.get_absolute_url()
>
> class Meta:
> ordering = ['name']
> unique_together = (('asset', 'name'),)
>
> class Admin:
> pass
>
> and the schema from "./manage.py sql asset":
>
> CREATE TABLE "asset_interface" (
> "id" serial NOT NULL PRIMARY KEY,
> "name" varchar(64) NOT NULL,
> "interfacetype_id" integer NOT NULL,
> "ipaddress_id" integer NOT NULL REFERENCES "ip_ipaddress" ("id"),
> "mac_address" varchar(24) NOT NULL,
> "domain" varchar(255) NOT NULL,
> "asset_id" integer NOT NULL REFERENCES "asset_asset" ("id"),
> UNIQUE ("asset_id", "name")
> );
>
>
> when I run "./manage.py sqlevolve asset" with absolutely no changes to
> my models it outputs:
>
> BEGIN;
> ALTER TABLE "asset_interface" ADD COLUMN "name_tmp" varchar(64);
> UPDATE "asset_interface" SET "name_tmp" = "name";
> ALTER TABLE "asset_interface" DROP COLUMN "name";
> ALTER TABLE "asset_interface" RENAME COLUMN "name_tmp" TO "name";
> ALTER TABLE "asset_interface" ALTER COLUMN "name" SET NOT NULL;
> COMMIT;
>
>
> Any ideas why it is doing this?
>
> regards
>
> matthew
>
> >
>
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: schema-evolution: status?
postgresql
On 14/09/06, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> which backend are you using?
>
> Matthew Flanagan wrote:
> > Derek,
> >
> > I have manually merged the trunk into my local working copy of the
> > schema-evolution branch and started playing with it. I wanted to
> > question the SQL "sqlevolve" is outputting. I have this model in an
> > application called "asset":
> >
> > class Interface(models.Model):
> > name = models.CharField(maxlength=64, core=True, db_index=True,
> > help_text='The name of the interface as given by the asset.')
> > interfacetype = models.ForeignKey(InterfaceType)
> > ipaddress = models.ForeignKey(IPAddress, verbose_name='IP Address',
> > raw_id_admin=True)
> > # allow for EUI-48 and EUI-64 addresses
> > mac_address = models.CharField(maxlength=24, blank=True,
> > help_text='The EUI-48 or EUI-64 physical address of the interface.')
> > domain = models.CharField(maxlength=255, blank=True,
> > help_text='The DNS domain this host resides in.')
> > asset = models.ForeignKey(Asset, edit_inline=models.TABULAR,
> > num_in_admin=10, num_extra_on_change=5)
> > objects = InterfaceManager()
> >
> > def _get_meta(self):
> > return self._meta
> > meta = property(_get_meta)
> >
> > def __str__(self):
> > return "%s:%s" % (self.asset, self.name)
> >
> > def get_absolute_url(self):
> > return self.asset.get_absolute_url()
> >
> > class Meta:
> > ordering = ['name']
> > unique_together = (('asset', 'name'),)
> >
> > class Admin:
> > pass
> >
> > and the schema from "./manage.py sql asset":
> >
> > CREATE TABLE "asset_interface" (
> > "id" serial NOT NULL PRIMARY KEY,
> > "name" varchar(64) NOT NULL,
> > "interfacetype_id" integer NOT NULL,
> > "ipaddress_id" integer NOT NULL REFERENCES "ip_ipaddress" ("id"),
> > "mac_address" varchar(24) NOT NULL,
> > "domain" varchar(255) NOT NULL,
> > "asset_id" integer NOT NULL REFERENCES "asset_asset" ("id"),
> > UNIQUE ("asset_id", "name")
> > );
> >
> >
> > when I run "./manage.py sqlevolve asset" with absolutely no changes to
> > my models it outputs:
> >
> > BEGIN;
> > ALTER TABLE "asset_interface" ADD COLUMN "name_tmp" varchar(64);
> > UPDATE "asset_interface" SET "name_tmp" = "name";
> > ALTER TABLE "asset_interface" DROP COLUMN "name";
> > ALTER TABLE "asset_interface" RENAME COLUMN "name_tmp" TO "name";
> > ALTER TABLE "asset_interface" ALTER COLUMN "name" SET NOT NULL;
> > COMMIT;
> >
> >
> > Any ideas why it is doing this?
> >
> > regards
> >
> > matthew
> >
> > >
> >
>
>
> >
>
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
