pure sql fixtures for tests

Hi, This is a bit of a continuation from this email in the other django group: https://groups.google.com/forum/#!topic/django-users/rRkYNt-cQOg The gist of it is this. More complex apps probably deal with with stored procedures, and columns not under direct django control (which is the case

Re: The model option's verbose_name_raw is not really that 'raw'

I see, thanks Didn't know the existence of the lazy translation, so this is all a big false alarm. -- 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 fro

The model option's verbose_name_raw is not really that 'raw'

Hi, I think I might have stumbled upon a small bug. According to its docs, the 'verbose_name_raw' property is supposed to return an untranslated version of the 'verbose_name' property. However, if LANGUAGE_CODE is set, then 'verbose_name' would already be translated, provided that the user wrot

Re: the new SELECT DISTINCT query in 1.3 rc1, and how to turn it off

I've created a ticket for this http://code.djangoproject.com/ticket/15559 Also, if someone else is stumbling on this problem, I went around it by providing a custom QuerySet class for my method, which has an overridden distinct method, that returns itself. -- You received this message because

the new SELECT DISTINCT query in 1.3 rc1, and how to turn it off

Hello, I'm testing my software with the new rc1 release of django 1.3, and I came onto a particularly nasty problem. I have a model which uses a Postgresql 'point' type, for which I've defined a field as: http://dpaste.com/472467/ I also have another model, which references this one with a fore

Recursive delete problem

Don't know why Django's ORM works in this way, but I think this may be a bug... This is how my model looks like: #- - - - - - - - - - - - - - - - - - - - - - - - - - - - - class Score(models.Model): . . . class Round(models.Model): . . . class Game(models.Model): round = mode

Re: manipulator.save(data) doesn't return a object from database

OK, thanks. Ivan Sagalaev wrote: > editable=False means exactly that manipulator won't touch this field, > this is why it's not updated with the value from data. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "D

manipulator.save(data) doesn't return a object from database

I don't know if this is a bug, so basicly this is a question not a bug report :) I have a model which has the next field: blabla = models.IntegerField(default=0, editable=False) Value for this field is calculated in the save(self) method of the model. But when I do: myObject = manipu

Re: SlugField utf-8 support

James Bennett wrote: > Even when I copy/paste that URL (which I had to do, because my > web-based email client didn't recognize that the Cyrillic portion of > it was part of the URL) into Firefox, the URL encoding turns > "��_��" into > "%D0%93%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0_%D1%81%D1%82%D1

Re: SlugField utf-8 support

gabor wrote: > and i'm sure you know that those cyrillic slugs, if part of an url will > get submitted in URLencoded form. even if it is hidden by the browser. Of course, every requested url must be URLencoded, but that is browsers job, and they all do it quite well. > slug = SlugField(only_a

Re: SlugField utf-8 support

The problem begins when you want to have nonenglish slug (slug on a language that uses nonascii characters). For example if I want to have a serban cyrillic slug: наслов_на_српском, it is perfectly valid slug if you read it on serbian, just aphanumeric characters + underscore + hyphen, nothing

SlugField utf-8 support

The story about non ASCII characters in slug started in #1602: urlify.js blocks out non-English chars. We tested utf-8 urls against ie, opera and konqueror and they work great. Firefox by default shows the urls urlencoded, but you can change: network.standard-url.escape-utf8 to false and