Re: CharFields and children defaulting to emtpy string

[Don Arbow]

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
-~--~~~~--~~--~--~---

OT : Django Trac crashes Safari

[Don Arbow]

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

[Don Arbow]

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: Serious problems with the way Django handles file uploads

[Don Arbow]

On Sep 14, 2006, at 9:41 PM, jp wrote:
>
> It is worth noting that parse_file_upload in django.http uses those
> email and mail libraries a lot. For what I don't know.

Django uses the email libraries to parse the uploaded content as HTTP  
uses MIME encoding for file uploads.

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: BooleanFields should default to False

[Don Arbow]

On Oct 2, 2006, at 9:14 PM, SmileyChris wrote:So, it seems obvious enough that a BooleanField should default to Falserather than return an empty string. What does an empty string mean interms of a BooleanField anyway? I'd assume False :)No, a BooleanField should not default to False, the default should be application specific. If you want a default value, specify it in your model definition. If you read the comments about models under null , it reads:"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."That way, if you don't provide a value for a boolean, it is stored as null, not as an empty string (nor converted to False).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: New filter proposal: None -> Blank Space

[Don Arbow]

On Oct 11, 2006, at 8:11 AM, Mario Gonzalez ( mario__ ) wrote:
>
>  Hello! I think we've been talking in irc, my nick is mario__  and now
> I really like to help to django code, if you let me.  Sometimes sql
> queries returns NULL values and python change that with a None type,
> then I cannot show a None in a web page so, I have to change that
> like:


There's already a filter called 'default_if_none', check the  
documentation.

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: Enhance enclose tag template process

[Don Arbow]

Here's a few things to think about when you start putting lots of  
logic code into your template.

What happens when your boss comes to you and says he wants the  
contents of that page in another format like xml or some corporate  
legacy reporting format? All your extraction logic is buried in the  
template, which needs to be duplicated in the xslt template, a real  
violation of DRY and a maintenance headache. Much easier to prepare  
the data in the view and feed it to a different template based on a  
view argument.

Django views can also be thought of as relational database views.  
Database views are sometimes used for security, so that certain  
columns of a table are not returned in a query if a specific user is  
not allowed to view them. If you start passing all data from a query  
into a template and let the template pick whatever data it needs to  
enforce this form of security, you're removing this security  
protection from the view. In large organizations where programming  
and design are separated, this protection can be easily violated  
through malice, neglect or ignorance.

When I code, my views always decide what data the template is allowed  
to have, the template decides how it should look. I like the fact  
that the minimal logic available in Django templates is specifically  
designed for presentational purposes (such as the date formatter) and  
efficient data generation (such as loops).

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?hl=en
-~--~~~~--~~--~--~---

Re: Moving towards Django 1.0

[Don Arbow]

On Jan 12, 2007, at 3:28 PM, John Sutherland wrote:
>
> On 12 Jan 2007, at 22:39, Jacob Kaplan-Moss wrote:
>> There's a few other things that aren't "unstable" per-se, but are
>> must-haves
>> for 1.0.  I know everyone's gonna have their own list -- and one of
>> the
>> purposes of this thread is to find that list -- but I'd like to
>> keep these
>> minimal.
>
> What's the story with model inheritance?


Wasn't this dependent on query refactoring that Malcolm was working on?

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?hl=en
-~--~~~~--~~--~--~---

Re: Moving towards Django 1.0

[Don Arbow]

On Jan 12, 2007, at 4:06 PM, Don Arbow wrote:

> Wasn't this dependent on query refactoring that Malcolm was working  
> on?
>


Doh, I send my post and Malcolm's response arrives at the same time...

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?hl=en
-~--~~~~--~~--~--~---

Re: svn properties ?

[Don Arbow]

On Jan 24, 2007, at 8:06 PM, Russell Keith-Magee wrote:
> On 1/25/07, Sean Perry <[EMAIL PROTECTED]> wrote:
>>
>> For example, admin A finds out about Django downloads a tarball /
>> checks out svn. He installs it to /usr/local/blah and writes some web
>> apps. At some point in the future admin B has to find out why an app
>> is not working and it turns out to be a Django bug. How does he know
>> where /usr/local/blah/django/broken.py came from? Is it 0.91?  
>> 0.95? 1.1?
>
> By looking at /usr/local/blah/django/__init__.py. This contains the
> version number for the Django install.



When I import a version of Django from the repository, I put a file  
in the top level of the django directory that tells me what changeset  
was checked out:

touch chngset.3499

Of course I'm not checking out daily builds so it's fairly easy. If I  
was syncing every day, I'd write a script to do the syncing and put  
the changeset file creation in there as well.

And you could always create a local mirror of Django's repository  
(which you could sync daily) and put your own svn properties in there.

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?hl=en
-~--~~~~--~~--~--~---

Re: svn properties ?

[Don Arbow]

On Jan 25, 2007, at 3:50 PM, Marc Fargas Esteve wrote:
> I'd then advocate for Don Arbow's solution, when you strip all the
> .svn directories you can add file telling the last revision pulled.
> something like django.VERSION would need to be updated on every new
> commit or it's revision would never cjange (note that the keyword Rev
> is really: LastChangedRevision whose name says it all).


Actually when I said check out, I really meant export. Then I don't  
have to download and delete all the .svn directories.

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?hl=en
-~--~~~~--~~--~--~---

Re: Comments requested on two serializer related fixes

[Don Arbow]

On Jan 29, 2007, at 5:22 AM, Russell Keith-Magee wrote:
>
> Hi All,
>
> I've just created two new tickets - #3389 and #3390.
>
> http://code.djangoproject.com/ticket/3389/
> http://code.djangoproject.com/ticket/3390/



These urls don't work with trailing slash, removing it works.

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?hl=en
-~--~~~~--~~--~--~---

Re: Is this group moderated, or is it a bug with google groups?

[Don Arbow]

On Feb 5, 2007, at 7:12 AM, Gary Wilson wrote:
> Is this spam filter stuff new with the new google groups or has it
> always been there?  I never had a problem before, but I posted several
> messages a couple days ago (on the evening of Feb. 3rd I believe) and
> about 1/3 of them have not shown up.



This filtering has been going on for some time. I don't think it's by  
author, but rather by content. If you think your messages are being  
held up, check the Raw Headers in your email program once your  
message arrives. You'll see something like this (this is from an  
actual message, note the date):

X-Google-Approved: [AH's google address] via web at 2006-08-31 14:55:38

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?hl=en
-~--~~~~--~~--~--~---

Re: +++spam+++

[Don Arbow]

On Friday, May 25, 2007, at 06:53 AM, simonbun wrote:

>
> Sorry, I thought tagging and reporting the spam to Google would help.
>


Exactly, but better to just go to Google and do that than spread more 
spam in this list.

There's no need whatsoever to acknowledge the spam within the list.

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?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Let session support backends

[Don Arbow]

On Jun 1, 2007, at 8:34 PM, kernel1983 wrote:
> I've write a session middleware myself instead of contrib.sessions. It
> uses memory instead of database. But it can be used only in dev mode
> just like the cache's simple backend.



Did you search Trac? This looks like it's already been proposed and a  
patch submitted:

http://code.djangoproject.com/ticket/2066

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?hl=en
-~--~~~~--~~--~--~---

Re: please help! need to know python version

[Don Arbow]

On Jul 5, 2007, at 10:19 AM, James Bennett wrote:
> Django is compatible with any version of Python greater than 2.3, as
> noted in the Django installation documentation:
>
> http://www.djangoproject.com/documentation/install/



You mean >=, right?  :-)

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?hl=en
-~--~~~~--~~--~--~---

Re: Supported versions of databases

[Don Arbow]

On Aug 1, 2007, at 9:14 AM, Malcolm Tredinnick wrote:
>
> - There are still people using PostgreSQL 7.x. Anything prior to  
> 7.3 is
> probably too hard to support. Setting the bar at 7.3 or 7.4 might be
> reasonable (I can't remember any big changes between those two).  
> 8.0 is
> too recent, since lots of corporates will still be running 7.x.


I am running Django with PostgreSQL 7.3.3. The get_sql_flush() method  
in django/db/backends/postgresql/base.py uses "ALTER SEQUENCE",  
rather than the older "SELECT setval()". This method was added for  
the test system's fixture loading. I patched base.py because "ALTER  
SEQUENCE" was not available until PostgreSQL 7.4.

Basically, you have code in one part of Django that works with 7.3  
and another that only works with 7.4. Should a ticket be filed? I'm  
not too concerned, I'll upgrade PostgreSQL eventually, but perhaps  
without a patch, users should be alerted that the command shell  
sequence reset works with 7.3 and the test system sequence reset  
requires 7.4.

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?hl=en
-~--~~~~--~~--~--~---

Re: Supported versions of databases

[Don Arbow]

On Aug 1, 2007, at 6:31 PM, Russell Keith-Magee wrote:
>
> On 8/2/07, Don Arbow <[EMAIL PROTECTED]> wrote:
>>
>> I am running Django with PostgreSQL 7.3.3. The get_sql_flush() method
>> in django/db/backends/postgresql/base.py uses "ALTER SEQUENCE",
>> rather than the older "SELECT setval()". This method was added for
>> the test system's fixture loading. I patched base.py because "ALTER
>> SEQUENCE" was not available until PostgreSQL 7.4.
>>
>> Basically, you have code in one part of Django that works with 7.3
>> and another that only works with 7.4. Should a ticket be filed?
>
> Please do. There is already some version-specific code in the Postgres
> backend (dealing with the way that flush operates) - if it is a
> relatively simple change to extend support to 7.3, I don't see any
> reason not to do so.
>



Done in http://code.djangoproject.com/ticket/5055

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?hl=en
-~--~~~~--~~--~--~---