Re: [Django] #7835: Provide the ability for model definitions that are only availably during testing

[Django]

#7835: Provide the ability for model definitions that are only availably during
testing
+---
  Reporter:  russellm   | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Testing framework  |   Version:  SVN
Resolution: |  Keywords:  feature test models
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by julien):

 Replying to [comment:13 russellm]:
 > Again, feel free to convince me otherwise, but my initial reaction is
 "yes". Tests shouldn't have side effects after their execution; stale
 entries sticking around the app cache have the potential to introduce this
 sort of side effects.

 I don't know if I can convince you for this one either, but I have one
 question: if the tests introduce such side effects, wouldn't that mean
 that the `AppCache` is buggy in the first place?

 The test framework already relies on many conventions. As long as one
 sticks to those (and assuming the `AppCache` is not buggy), then I tend to
 think that everything would go fine. Obviously, if one is not careful
 enough and does not follow the conventions, then things could crash
 miserably.

 Also, considering the proposed API, how would we know which app to unload,
 since we may include some apps that have already been loaded by the test
 suite (e.g. the most common ones like `contenttypes` or `auth`).

 All these considerations depend on whether on not the suggested API is
 adequate. You haven't commented much on that yet. Could you share your
 thoughts on the quality of the API and how it could be improved?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7835: Provide the ability for model definitions that are only availably during testing

[Django]

#7835: Provide the ability for model definitions that are only availably during
testing
+---
  Reporter:  russellm   | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Testing framework  |   Version:  SVN
Resolution: |  Keywords:  feature test models
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by julien):

 Replying to [comment:12 russellm]:
 > If an additional call to syncdb is completely unavoidable, then so be
 it; however, I'm not yet convinced that it is unavoidable. Feel free to
 convince me :-)

 The proposed API allows one to add *any* app to `INSTALLED_APPS`, that is,
 some that may have already been synced (e.g. the common ones like
 `contenttypes` or `auth`) and some that probably haven't been synced yet
 (typically the app's internal test apps). Therefore I think that a
 synchronisation is necessary because we can't predict which apps have been
 synced or not yet.

 You say that "there is a already a syncdb being called as part of the
 flush". This is not exactly true because my patch simply won't work
 without an explicit call to `syncdb`: `flush` does not create tables for
 the dynamically added apps which haven't been synced yet.

 But even so, I don't think it would have such a latency impact. Assuming
 that this new API ever gets checked in, I presume only (or mostly) the
 contrib apps would bother using it so they become more self-contained (I'm
 talking in the context of the Django test suite). And, with the boost
 improvement scheduled for 1.1 (all tests run in one transaction), these
 considerations might well be negligible anyway.

 Finally (and maybe more importantly) I am not sure how to go without
 `syncdb` :) Any hint?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7835: Provide the ability for model definitions that are only availably during testing

[Django]

#7835: Provide the ability for model definitions that are only availably during
testing
+---
  Reporter:  russellm   | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Testing framework  |   Version:  SVN
Resolution: |  Keywords:  feature test models
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by russellm):

 Replying to [comment:10 julien]:
 > The only thing that was requested and which I haven't done is unloading
 the test apps from the `AppCache`. But, is it really necessary?

 Again, feel free to convince me otherwise, but my initial reaction is
 "yes". Tests shouldn't have side effects after their execution; stale
 entries sticking around the app cache have the potential to introduce this
 sort of side effects.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7835: Provide the ability for model definitions that are only availably during testing

[Django]

#7835: Provide the ability for model definitions that are only availably during
testing
+---
  Reporter:  russellm   | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Testing framework  |   Version:  SVN
Resolution: |  Keywords:  feature test models
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by russellm):

 Replying to [comment:11 julien]:
 > Oh, another note. In the code patch, I still need to run `syncdb` to
 create potential new tables for the test apps' models. I don't think this
 can really be avoided. And I don't think this is a problem either.

 The problem isn't (just) one of code neatness - it's the execution time
 for the tests. On my machine, the full Django's system test suite takes
 about 5 minutes to execute for SQLite; almost 10 minutes to run for
 Postgres. I haven't run the Oracle tests myself, but I've been lead to
 believe that it goes from "go make yourself a cup of coffee" to "go make
 yourself a 9-course degustation banquet". I'm going to be very picky about
 introducing anything that has the potential to make this situation worse.

 Syncdb isn't a no-op when there is nothing to do. Given that there is a
 already a syncdb being called as part of the flush, my initial reaction is
 that you shouldn't need another one. This may mean that there are some
 other modifications that need to be made; I'm not opposed to making such
 changes, if they're required.

 If an additional call to syncdb is completely unavoidable, then so be it;
 however, I'm not yet convinced that it is unavoidable. Feel free to
 convince me :-)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9715: r9110 introduced Backwards-Incompatible change

[Django]

#9715: r9110 introduced Backwards-Incompatible change
-+--
  Reporter:  telenieko   | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  invalid |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by telenieko):

 Replying to [comment:1 mtredinnick]:
 > Sorry that it clashed with a local change you made, but it really can't
 be helped.

 Np, I do not care that much. But there may be a big a big bold note in the
 1.1 release notes saying "If you have a --verbosity parameter in a custom
 management command it will break" ;)

 Thanks for the comments on api-stability to both of you! ;)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9723: r9527 (compressed fixtures) breaks loaddata for some Pythons

[Django]

#9723: r9527 (compressed fixtures) breaks loaddata for some Pythons
---+
 Reporter:  AdamG  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Serialization  | Version:  1.0   
 Keywords:  fixtures   |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 The `bz2` stdlib module is optional, and not compiled in all Pythons.
 r9527 breaks loaddata for those Pythons by having a top-level import for
 the module. Patch against trunk attached to fix the issue. The patch is
 untested, as I don't have a Python installation without bz2 to test with.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9719: Strings which look like numbers are not quoted, MySQL

[Django]

#9719: Strings which look like numbers are not quoted, MySQL
---+
  Reporter:  anonymous | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 You are confusing a couple of things here. Not denying there's a bug
 (although your description seems to involve a lot of steps to repeat it).
 However, the output of connection.queries is not exactly what is passed to
 the database. The database wrapper (the bit between Django and the
 database) does parameter quoting. We have no way of accessing that quoting
 function (it's not public API), so we just print out the value without
 quotes. Thus, the output of connection.queries is not a reliable indicator
 of the bytes sent to the database.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9722: Use pyinotify (where available) instead of polling filesystem every second to detect changes

[Django]

#9722: Use pyinotify (where available) instead of polling filesystem every 
second
to detect changes
---+
 Reporter:  lamby  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  django-admin.py runserver  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 This patch series adds support for pyinotify to replace the "poll-every-
 one-second" mechanism in django.utils.autoreload on systems where that
 library is available.

 Inotify is an event-driven notifier for monitoring filesytems changes.
 Instead of dancing around the filesystem comparing modification times
 every second, we can simply register all the files we are interested in
 and let the thread block until one of them changes. When this happens, we
 reload the server as before.

 This has the following advantages over the current polling system:

  * Scales far better to larger projects.
  * Response time to code changes is drastically reduced - the server
 restarts pretty much instantly instead of having to wait ~0.5 seconds for
 the reload.
  * More robust change detection - pretty much all forms of modification of
 the interested file are noticed (in particular, moving the file and
 editing the file without changing the mtime)
  * Saves battery usage - I have to use --noreload on my laptop (with
 encrypted filesystems) as it noticably reduces my battery life. Django is
 killing kittens.
  * Cleaner implementation - Polling is just dirty, and requires us to
 maintain a huge dict full of modification times.

 Whilst inotify is Linux-specific, the patch gracefully degrades if a
 suitable version of pyinotify is not available. It does not add pyinotify
 as a dependency to Django.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7835: Provide the ability for model definitions that are only availably during testing

[Django]

#7835: Provide the ability for model definitions that are only availably during
testing
+---
  Reporter:  russellm   | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Testing framework  |   Version:  SVN
Resolution: |  Keywords:  feature test models
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by julien):

 Oh, another note. In the code patch, I still need to run `syncdb` to
 create potential new tables for the test apps' models. I don't think this
 can really be avoided. And I don't think this is a problem either.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7835: Provide the ability for model definitions that are only availably during testing

[Django]

#7835: Provide the ability for model definitions that are only availably during
testing
+---
  Reporter:  russellm   | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Testing framework  |   Version:  SVN
Resolution: |  Keywords:  feature test models
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by julien):

 So I have finally migrated the tests for `contrib.comments` which seems a
 more doable intermediary step before migrating huge tests like the
 admin's. I also wrote a piece of documentation to present the new API and
 a suggested convention for avoiding app name clashes.

 The only thing that was requested and which I haven't done is unloading
 the test apps from the `AppCache`. But, is it really necessary? It will be
 highly recommended to developers to follow a certain convention to avoid
 name clashes. If they do so, then unloading the models/apps from the cache
 won't be crucial to do. If they don't do so, then there might be a whole
 lot of unpredicted conflicts at several other levels anyway. Ideas?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9492: Invalid XHTML in admin/base.html template

[Django]

#9492: Invalid XHTML in admin/base.html template
---+
  Reporter:  dc| Owner:  wilson
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 $0.02: Maybe we should assume that sane users are running IE 8 which
 requires less in the way of special case care-and-feeding. Antique
 versions of IE should be forgotten as quickly as possible, rather than
 supported by conditional trickery Let the nightmare end for web
 developers everywhere!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #2507: [patch] LDAPBackend in django/contrib/auth/backends.py

[Django]

#2507: [patch] LDAPBackend in django/contrib/auth/backends.py
---+
  Reporter:  [EMAIL PROTECTED]  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  SVN   
Resolution:|  Keywords:  ldap,usernames
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  1 |  
---+
Changes (by programmerq):

  * needs_tests:  0 => 1

Comment:

 Replying to [comment:26 spkane]:
 > ldapauth.patch (4.5 kB) - added by spkane on 10/24/08 10:33:11.
 > This patch is reasonably specific to my needs, but I would bet hard
 money, that this is an issue faced by other people, so a more robust
 version of this patch should likely be considered. The issue is that the
 best thing for me to use as a username within our LDAP implementation is
 the prefix of the email address, since it is the only thing guaranteed to
 be unique (we have many employees with the same name). However, our email
 addresses are, [EMAIL PROTECTED] Django does not allow a period
 in the username, so I added some logic to handle the username (for django)
 and the ldap_username separately and use the proper one in the proper
 place. Basically, the users login as "sean_kane" and the ldap backend
 converts that to "sean.kane" when talking to the ldap server and then uses
 "sean_kane" when talking to the Django server.

 I'm not sure that's where that kind of logic belongs. I'd be inclined to
 use the cn as the "username" field, and then just tell users to login with
 their e-mail address. I've never implemented that, but I've heard of
 people using the Django auth system in such a way that people can log in
 with their e-mail address instead of their username. You'd basically just
 have to roll your own login forms, and make sure your views don't spit out
 the actual "username"-- they'll just spit out the e-mail address.

 I've also seen some discussion come up about allowing dots in a username.
 I don't know where that discussion went though. Ultimately the decision to
 include this logic in the ldapbackend will need to come from a core dev,
 but I'm a big fat -1 on the issue.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #2507: [patch] LDAPBackend in django/contrib/auth/backends.py

[Django]

#2507: [patch] LDAPBackend in django/contrib/auth/backends.py
---+
  Reporter:  [EMAIL PROTECTED]  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  SVN   
Resolution:|  Keywords:  ldap,usernames
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by programmerq):

 I intend to write tests for this patch using the {{{iw.mock.ldap
 module}}}. This is a very low priority project for me. I'll likely work on
 it at/during a sprint-- it'd be nice to finally have included. The patches
 submitted are kind of a mess-- some are patches, some are standalone
 python files.

 This ticket needs to have the docs, new code, and tests in a single patch
 file in order for it to be ready for check-in. I'll do my best to sort
 through the various versions of the patch and see if I can get something
 in the right format. Right now it's a big mess. :)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9678: Flatpage with URL of "/" ends up in a redirect loop.

[Django]

#9678: Flatpage with URL of "/" ends up in a redirect loop.
+---
  Reporter:  watusee| Owner:  nobody  
Status:  closed | Milestone:  post-1.0
 Component:  Uncategorized  |   Version:  1.0 
Resolution:  worksforme |  Keywords:  flatpage
 Stage:  Unreviewed | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by dih0658):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => worksforme
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 I've been using a site with a flatpage as it's root for quite some time. I
 went back to double check that I wasn't losing my mind and tried both
 APPEND_SLASH options. All works just fine for me.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9721: DateTimeField does not support all DEFAULT_DATETIME_INPUT_FORMATS when passed a list as input

[Django]

#9721: DateTimeField does not support all DEFAULT_DATETIME_INPUT_FORMATS when
passed a list as input
---+
 Reporter:  uggedal|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Forms  | Version:  SVN   
 Keywords:  DateTimeFIeld SplitDateTimeWidget  |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 When using for instance a SplitDateTimeWidget with a DateTimeField one can
 not provide valid input to be parsed with the following formats:

 {{{
 '%Y-%m-%d',  # '2006-10-25'
 '%m/%d/%Y',  # '10/25/2006'
 '%m/%d/%y',  # '10/25/06'
 }}}

 One can therefore not create a split input solution where the time
 component is not required. The reason lies in SplitDateTimeWidget's clean
 method for list input. The date and time parts are concatenated together
 with a space between them. I included a patch for the simplest thing that
 would work (albeit possible not the best way to handle this).

 SplitDateTimeField exists, but this field explicitly requires both date
 and time fields to be included.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9720: dbshell attempts to connect to mysql as user 'ODBC'@'localhost' which fails

[Django]

#9720: dbshell attempts to connect to mysql as user 'ODBC'@'localhost' which 
fails
+---
  Reporter:  jfenwick   | Owner:  nobody   
Status:  closed | Milestone:   
 Component:  Uncategorized  |   Version:  SVN  
Resolution:  invalid|  Keywords:  mysql dbshell
 Stage:  Unreviewed | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by programmerq):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => invalid
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 The ticket system is for issues with Django's code. Please use the django-
 users google group for usage and support questions.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9720: dbshell attempts to connect to mysql as user 'ODBC'@'localhost' which fails

[Django]

#9720: dbshell attempts to connect to mysql as user 'ODBC'@'localhost' which 
fails
---+
 Reporter:  jfenwick   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  SVN   
 Keywords:  mysql dbshell  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 When I try to run dbshell to connect to a mysql database I get the error:

 ERROR 1045 (28000): Access denied for user 'ODBC'@'localhost' (using
 password: NO)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9719: Strings which look like numbers are not quoted, MySQL

[Django]

#9719: Strings which look like numbers are not quoted, MySQL
--+-
 Reporter:  anonymous |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Create a simple model with a CharField.[[BR]]
 Create a ModelForm for that model.

 The model can be created successfully and saved to the database using
 CharField data which looks like a number (e.g. IP address), but updating
 that model using the same ModelForm fails if the data already existing in
 the database looks like a number.


 {{{
 form = Config(request.POST, instance=mymodel) # A form bound to
 the POST data
 if form.is_valid(): # All validation rules pass
 try:
 form.save()  # Throws blank exception
 }}}


 The SQL query that fails (from db.connection.queries) is:


 {{{
 SELECT  FROM `service_config` WHERE (`service_config`.`customer_id` =
 1  AND `service_config`.`hostname` = 192.168.1.20
 }}}

 The last item should be in quotes. MySQL will fail on this statement, and
 the Exception returned from ModelFormInstance.save() is blank (printing
 the exception results in a null string).

 Change the data to 'X192.168.1.20' and it works as expected.

 This occurs in at least 1.0.1 and 1.0.2.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9536 - in django/branches/releases/1.0.X: . django/core/management

[noreply]

Author: russellm
Date: 2008-11-29 05:55:05 -0600 (Sat, 29 Nov 2008)
New Revision: 9536

Modified:
   django/branches/releases/1.0.X/
   django/branches/releases/1.0.X/django/core/management/sql.py
Log:
[1.0.X] Fixed #9717 -- Corrected a problem where django-admin.py flush would 
attempt to flush database tables that had not yet been created. This occurred 
when an application had been added to INSTALLED_APPS, but had not yet been 
synchronized. Thanks to Julien Phalip for the patch.

Merge of [9535] from trunk.



Property changes on: django/branches/releases/1.0.X
___
Name: svnmerge-integrated
   - 
/django/trunk:1-9097,9099-9102,9104-9109,9111,9113-9144,9146-9151,9153-9156,9158-9159,9161-9187,9189-9247,9249-9262,9264-9277,9279-9298,9301-9302,9305-9331,9333-9343,9345,9347,9350-9352,9355-9396,9399-9462,9466-9469,9471-9488,9491-9523
   + 
/django/trunk:1-9097,9099-9102,9104-9109,9111,9113-9144,9146-9151,9153-9156,9158-9159,9161-9187,9189-9247,9249-9262,9264-9277,9279-9298,9301-9302,9305-9331,9333-9343,9345,9347,9350-9352,9355-9396,9399-9462,9466-9469,9471-9488,9491-9523,9535

Modified: django/branches/releases/1.0.X/django/core/management/sql.py
===
--- django/branches/releases/1.0.X/django/core/management/sql.py
2008-11-29 11:51:41 UTC (rev 9535)
+++ django/branches/releases/1.0.X/django/core/management/sql.py
2008-11-29 11:55:05 UTC (rev 9536)
@@ -119,13 +119,13 @@
 def sql_flush(style, only_django=False):
 """
 Returns a list of the SQL statements used to flush the database.
-
+
 If only_django is True, then only table names that have associated Django
 models and are in INSTALLED_APPS will be included.
 """
 from django.db import connection
 if only_django:
-tables = connection.introspection.django_table_names()
+tables = 
connection.introspection.django_table_names(only_existing=True)
 else:
 tables = connection.introspection.table_names()
 statements = connection.ops.sql_flush(style, tables, 
connection.introspection.sequence_list())


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9535 - django/trunk/django/core/management

[noreply]

Author: russellm
Date: 2008-11-29 05:51:41 -0600 (Sat, 29 Nov 2008)
New Revision: 9535

Modified:
   django/trunk/django/core/management/sql.py
Log:
Fixed #9717 -- Corrected a problem where django-admin.py flush would attempt to 
flush database tables that had not yet been created. This occurred when an 
application had been added to INSTALLED_APPS, but had not yet been 
synchronized. Thanks to Julien Phalip for the patch.

Modified: django/trunk/django/core/management/sql.py
===
--- django/trunk/django/core/management/sql.py  2008-11-26 21:22:07 UTC (rev 
9534)
+++ django/trunk/django/core/management/sql.py  2008-11-29 11:51:41 UTC (rev 
9535)
@@ -119,13 +119,13 @@
 def sql_flush(style, only_django=False):
 """
 Returns a list of the SQL statements used to flush the database.
-
+
 If only_django is True, then only table names that have associated Django
 models and are in INSTALLED_APPS will be included.
 """
 from django.db import connection
 if only_django:
-tables = connection.introspection.django_table_names()
+tables = 
connection.introspection.django_table_names(only_existing=True)
 else:
 tables = connection.introspection.table_names()
 statements = connection.ops.sql_flush(style, tables, 
connection.introspection.sequence_list())


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9718: Reference to 'FormWrapper objects' in auth docs is confusing

[Django]

#9718: Reference to 'FormWrapper objects' in auth docs is confusing
--+-
 Reporter:  [EMAIL PROTECTED]  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Documentation | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 From the docs of the login view in user auth docs:
 http://docs.djangoproject.com/en/dev/topics/auth/?from=olddocs

 "form: A Form object representing the login form. See the forms
 documentation for more on FormWrapper objects."

 What are "FormWrapper" objects? It seems like something long gone, because
 I can't find any more references to it in the docs.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9717: manage.py flush raises error if there are unsynchronized applications

[Django]

#9717: manage.py flush raises error if there are unsynchronized applications
--+-
  Reporter:  russellm | Owner:  nobody
Status:  new  | Milestone:
 Component:  django-admin.py  |   Version:  1.0   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Comment (by russellm):

 Replying to [comment:2 julien]:
 > So, I guess that to properly test this, one would need to be able to
 include apps dynamically in the test suite, a problem which #7835 is
 trying to solve. Looks like a "chicken or the egg" puzzle :)

 This is one of the rare occasions where it is acceptable to not include a
 unit test with a patch. There are a number of areas of Django that aren't
 unit tested - for example, most of the behaviour of syncdb is not formally
 tested. This isn't ideal, but sometimes it is unavoidable - usually
 because the cost of setting up the infrastructure required for testing
 these edge cases vastly exceeds the benefit that will be returned,
 especially given the frequency with which those areas of code are modified
 is taken in to consideration.

 I'll take a look at this patch tonight.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---