In my case, I had to remove mysql_replicated as our db backend. We're
no longer using mysql_replicated so I haven't tried to find the source
of the incompatibility, but this was the source of this error message
for us.
On Nov 10 2009, 12:57 pm, Evgeny wrote:
> I think I found a workaround:
> fir
Malcolm,
Thanks a lot for the pointer. For anyone else interested, here is
what my settings-test.py looks like:
from settings import *
# CSRF Middleware breaks auth tests
MIDDLEWARE_CLASSES = list(MIDDLEWARE_CLASSES)
MIDDLEWARE_CLASSES.remove
('django.contrib.csrf.middleware.CsrfMiddleware')
the urlpatterns += line looks right, but I don't really know what
you're doing with the # lines. Could you post the full
mysite.myproject.urls file?
On Jan 22, 9:18 am, NoviceSortOf wrote:
> Looking at mysite.myproject.urls I have...
>
> urlpatterns += patterns('', (r'^profiles/', include
> ('p
What is the best way to disable a specific middleware when running
django tests?
This ticket was designated wontfix, so I get test failures on the auth
tests every time I run our test suite:
http://code.djangoproject.com/ticket/9172#comment:12
I'd prefer not to have to edit settings.py every tim
So, I haven't had this problem specifically, but all the tests I've
written don't make changes to DJANGO_PATH or os.environ. I believe the
test runner takes care of this automatically.
If your tests are in project/app/tests.py
and you're running them with:
python manage.py test
you should be o
Hi, I want to provide unique attributes to each radio button in a
RadioSelect widget to integrate with several AJAX effects. Ideally
the code produce would look something like this:
All books
In print books
Out of print books
Only these books
Basically, when the last radio button
As it turns out, TestCase only flushes the database before a test. It
doesn't flush it after it has finished its tests.
On Sep 24, 10:18 am, davenaff <[EMAIL PROTECTED]> wrote:
> I'm running into a bizarre bug? in the test utilities. Basically, a
> fixture imported as par
I'm running into a bizarre bug? in the test utilities. Basically, a
fixture imported as part of a django testcase is persistent and the
data in the fixture is appearing in doctests for a separate
application.
I have two apps:
app1
- uses the fixture in test case
app2
- doctest
If I run "test
nal=signals.pre_save,
sender=User)
Then create a tests.py and add this import (that's all you need):
from myproject.models import MyModel
You'll get the behavior I displayed earlier. I'll see if I can figure
out what is causing this.
Dave
On Jul 9, 10:15 am, davenaff <[EMAI
To add more detail:
The db version of the file won't be removed until the save method is
complete.
def save(self):
if self.id:
#The photo currently exists
m = MyModel.objects.get(pk=self.id)
if m.photo == self.photo:
#They are the same photo
else:
Alternatively you can use the xml Element Tree (included in python
2.5) library for building and parsing your xml file:
http://effbot.org/zone/celementtree.htm
Then of course use urllib/urllib2 (a good reference is here:
http://www.voidspace.org.uk/python/articles/urllib2.shtml)
Dave
On Jul 9,
This behavior is really quite bizarre and I've spent a tremendous
amount of time trying to figure it out.
Here is the code to demonstrate the problem: In one of my models.py
files, I have this:
COUNT = 0
def user_pre_save(sender, instance, signal, *args, **kwargs):
global COUNT
Awesome, this is very helpful.
Thanks!
On Jun 25, 5:09 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Wed, 2008-06-25 at 00:42 -0700, bruno desthuilliers wrote:
> > On 25 juin, 01:03, davenaff <[EMAIL PROTECTED]> wrote:
> > > In a template, I'm us
In a template, I'm using the equivalent of:
{% for field in form %}
{{ field.label_tag }}{{field}}
{% endfor %}
However, the labels of my hidden fields appear. Is there an easy way
to test if the field is using the HiddenInput widget (or an alternate
solution)?
Thanks!
--~--~-~--~~-
I concur with Oliver.
Obviously if your dynamic user_name is a variable, it would look like
this:
form=MyForm(initial={'user_name':user_name})
And of course, this is written in the view.
On May 12, 2:41 pm, oliver <[EMAIL PROTECTED]> wrote:
> I do it like this:
>
> def frommagic(request):
>
Over the weekend I ran into problems getting doctests to run. I found
that imports in other modules were causing the model classes to not be
recognized by _doctest:
http://groups.google.com/group/django-users/browse_thread/thread/10f82ec0cea4ee3b
I ran out of time before I was able to determine
:
from projectname.appname.models import *
the doctests in models.py are run, but I get execution errors in
util1.py.
On May 10, 7:44 pm, davenaff <[EMAIL PROTECTED]> wrote:
> Thanks for the note. I actually just resolved this.
>
> I had created a module that resided in the ap
? I shouldn't need to include the projectname in
modules that are fully contained within an app.
On May 10, 7:18 pm, phillc <[EMAIL PROTECTED]> wrote:
> can we see your models.py?
>
> On May 10, 9:00 pm, davenaff <[EMAIL PROTECTED]> wrote:
>
> > It is probably also
It is probably also worth noting that _doctest returns correct
(projectname.appname.models) object.__module__ values for Managers.
On May 10, 5:49 pm, davenaff <[EMAIL PROTECTED]> wrote:
> As I dig into this, I've found that the problem is that the classes in
> my models.py f
g the
full path.
Any ideas?
Dave
On May 10, 3:49 pm, davenaff <[EMAIL PROTECTED]> wrote:
> I've just begun using doctests and when I run manage.py test appname,
> the doctests in the models.py file aren't running.
>
> I have other apps in the project that have doctest
I've just begun using doctests and when I run manage.py test appname,
the doctests in the models.py file aren't running.
I have other apps in the project that have doctests that run fine.
I also have taken the models in this app and pasted them into a
different app. The doctests run fine in that
It sounds like you have an application configured to open .py files.
Try: python manage.py etc.
On May 10, 12:04 pm, garrettjohnson <[EMAIL PROTECTED]> wrote:
> i just moved back to windows (after a horrible hardy heron update)...
>
> Everything seemed to install just fine, its in my site-packag
This might be a syntax problem. This is the syntax I use:
object, created = Entity.objects.get_or_create(id=12)
On Apr 28, 12:12 pm, Thierry <[EMAIL PROTECTED]> wrote:
> The get or create syntax does not appear to support the following
> syntax:
>
> object, created = get_or_create(entity_id = 12
Awesome work. Thanks!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTE
I think everyone was given a denied message initially. I got an
acceptance note around 10:15, but haven't had time to play around with
it yet.
On Apr 7, 9:14 pm, shabda <[EMAIL PROTECTED]> wrote:
> I got the news too late, and no more invites were avialable. Anyone
> who is using this, and their
I've been having problems with unit tests that check the response
status codes of various pages.
When PREPEND_WWW is set to True (as in test and prod), the Django test
client returns a status code of 301 instead of 200 for any requested
url (as dev is set up).
Has anyone figured out a solution t
t; That can probably be done without the list comprehension but this
> should work.
>
> On Mar 24, 7:23 pm, davenaff <[EMAIL PROTECTED]> wrote:
>
> > This seems like something that should be doable, but I can't seem to
> > make it work.
>
> > Consider an
This seems like something that should be doable, but I can't seem to
make it work.
Consider an example with these models:
class Book(models.Model):
author = models.ForeignKey(Author)
publisher = models.ForeignKey(Publisher)
pub_date = models.DateTimeField()
is_hardcover = models.BooleanF
You need to send initial values to the form when you define the form
in its view.
For example, this call would intialize the form with your data:
form = myform(initial={'company':myprofileinfo.company,
'gender':myprofileinfo.gender,})
where 'company' and 'gender' correspond to the names of your
Tim,
This was super helpful. Thanks for the guidance. For anyone that
finds this via search, I'd also recommend reading here:
http://www.djangoproject.com/documentation/db-api/#chaining-filters
Dave
On Feb 29, 5:52 am, Tim Chase <[EMAIL PROTECTED]> wrote:
> > A few classes (sorry for the syn
Thanks for your responses.
I don't think my question was all that clear, however, thanks to Ivan
I've found the similar discussion topic he referenced:
http://groups.google.com/group/django-users/browse_thread/thread/d1649d9d6153b948/233ca8422a73cd3e?lnk=gst&q=class+static+manager+methods#233ca8
What are the best practices for using Managers?
>From the Django model reference, I find this quote
"Adding extra Manager methods is the preferred way to add "table-
level" functionality to your models. (For "row-level" functionality --
i.e., functions that act on a single instance of a model ob
32 matches
Mail list logo
