client. On exit from the with transaction.atomic() which
wrapped the DELETE FROM statements, the records are still in the tables!
Can anyone tell me what's going on, or point to some other way of
initialising a test database *completely* from a fixture file?
Regards,
Vinay Sajip
--
You received
ul, as always. I'll
mull things over and see what's the best for the specifics of the specific
project.
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
management commands shows there's a lot of usage of
connections[options.get('database')] going on, and yet externally written
management commands aren't encouraged to use the same approach, and
multiple settings files are the suggested alternative?
Regards,
Vinay Sajip
--
You received this
nsaction.atomic(), of course, but backwards compatibility is a
constraint I'm aware of :-)
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
settings.DATABASES[alias]
just before the with block, and it had no effect - the result was the same
- so I took it out. How else are you supposed to override the default
database?
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
&
was imported, even though it is being overridden in the
command line. If not actually a bug, this behaviour doesn't seem
particularly intuitive, so any advice would be gratefully received.
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django
On Jan 30, 1:36 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Wed, 2009-01-28 at 23:21 -0800, Vinay Sajip wrote:
>
> [...]
>
> > I was hoping there was another way. Of course subclassing's not hard
> > to do, but it means doing it for ev
On Jan 29, 12:35 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Wed, 2009-01-28 at 04:27 -0800, Vinay Sajip wrote:
> > I'd like to attach some user-defined meta-information to individual
> > model fields and have it also be available in the corresponding for
=some_object)
active = models.BooleanField(info=some_other_object)
Ideally, this information would be available in the corresponding form
field.
What's the best way of achieving this DRY-ly?
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this message because you
his. Then individual apps
never need be concerned about where their logging output is going (in
fact they shouldn't hardcode this type of information, especially if
they are meant to be reusable).
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this message b
mpleted the download
(accounting for the OK PDF file) but failed to rename it, you might
get the result which you observed.
I use a slightly different content-disposition, indicating explicitly
that it's an attachment:
response['Content-Disposition'] = 'attachment; filename=gisplan.pdf
g/
http://www.linuxquestions.org/linux/answers/Applications_GUI_Multimedia/Setting_up_a_PDF_printer_in_CUPS_in_my_case_in_Slackware
Of course with a PDF printer you don't get full control of the PDF
produced. For better control, ReportLab is the ticket, and not as hard
as it
this time we'll also produce a alternative version which will
> be more suited for non-colour printing.
>
Nice cheat sheet. Hope it's not too late to offer a suggestion - it
would be useful to have the forloop special variables in the cheat
sheet. Not sure where you'll find room, though
rofile().attr and use user.attr
instead.
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
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
On May 14, 10:15 am, Bram - Smartelectronix <[EMAIL PROTECTED]>
wrote:
> In my opinion there's only one easy solution which doesn't create
> ridiculous overhead and that is to be able to add fields to the User
> model without having to hack the actual code of the User model. Does
> anyone agree
PROTECTED]:~$ python
Python 2.5.1 (r251:54863, May 2 2007, 16:56:35)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
It's labelled Pyt
On May 18, 12:30 pm, Guyon Morée <[EMAIL PROTECTED]> wrote:
>
> I agree that would be nice, but wouldnt that mean that django is
> serving the files?
>
Not necessarily. The wrapper view could check permissions and issue a
redirect to the static site if the user has a right to see the image,
or
Are you looking for contract developers, permanent developers or
either?
--~--~-~--~~~---~--~~
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
On May 11, 4:20 pm, Maxim Bodyansky <[EMAIL PROTECTED]> wrote:
> Hmmm. It just works. And i18n for module names works too :)
> Many-many thanks, Ivan :)
Это не Иван, это - Vinay
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
in any feedback, and particularly from
Joseph Kocherhans, whose ideas I used from an earlier patch to the
same ticket (#3591). If the patch works for you - please take the
trouble to feed that back to the list, too.
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You receiv
other language), use this patch:
http://code.djangoproject.com/attachment/ticket/3591/app_labels.5.diff
Then, run make-messages.py, update the translations in the .po files,
run compile-messages.py and you should be able to show
internationalized app names and
On May 9, 7:21 pm, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> It appears not. Just to see if it would work, I tried just adding
> overriding __getattribute__ (which just calls the superclass
> behaviour) and it causes some unexpected behaviour in the unit tests.
False alarm - it w
On May 9, 6:37 pm, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> part of the user model. Is the intention just to avoid saying
> user.get_profile().xxx? Can't this be done by judiciously overriding
> __getattribute__ in User, to delegate to a profile if one is defined?
It appears n
be done by judiciously overriding
__getattribute__ in User, to delegate to a profile if one is defined?
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this
ess:
I believe this is the same error as logged in ticket #3954, for which
a fix has been checked in (changeset #5102).
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" gro
n macOSX. I
> have tested on Ubuntu and I get a similar error. Is it a bug?
>
It's logged on the tracker - see
http://code.djangoproject.com/ticket/3954
The good news is, it's a one-line patch - there's a missing call to
disable_termcolors() in load
On Apr 8, 2:01 pm, "Deryck Hodge" <[EMAIL PROTECTED]> wrote:
> On 4/8/07, Vinay Sajip <[EMAIL PROTECTED]> wrote:
>
> I have a logger setup for use at work, and I control it via a
> LOG_LEVEL setting in settings.py. I don't have logging statements
> th
del-class invariant
method to check if, from the model point of view, the model instance
is valid. (Note that the model point of view can be stricter and also
more complex than database constraints can easily capture.) If the
invariant fails, an exception can be thrown, and caught in the view to
display a
d be happy to submit a patch - just wanted to canvass opinion here
before raising a ticket.
Cheers,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send e
e your feedback.
Thanks,
Vinay Sajip
--~--~-~--~~~---~--~~
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 gr
model definition or instance
> instantiation).
Thanks Russ, I figured it out. It didn't really need to be done on
module load - I was justy trying to do it as early as possible.
Anyway, model definition time is fine, and when I moved the code from
__init__.py to models.py, the
s would be initialised in the order that they appear
in
INSTALLED_APPS, and mysite.myapp (being last in the list) should be
able to rely
on the preceding apps being initialised already. If this is not the
case, where
is the best place to do the kind of initialisation I want to?
Thanks in advance,
32 matches
Mail list logo
