Possible through basic Python:
obj_list = [ i for i in MyObject.objects.all() where my_filter(i) ]
Note that this filtering is happening on the Python side of things,
whereas a queryset filter is executed in SQL on the database. The
filtering on the database is normally much, much faster, so b
Typo...
The correct syntax is :
obj_list = [ i for i in MyObject.objects.all() if my_filter(i) ]
On Jun 5, 4:29 pm, johan de taeye wrote:
> Possible through basic Python:
>
> obj_list = [ i for i in MyObject.objects.all() where my_filter(i) ]
>
> Note that this filtering
Hello,
In my application a number of databases are configured with identical
schemas.
>From a dropdown box on the screen, the user selects the database he/
she wants to work with. The selected database is stored on the
cookie.
An object with the same primary key can be created in each schema by
t
> You can't do this with a router; as you've noted, the router doesn't
> have any information about the request in which it is being used.
>
> However, you could do it by manually requesting your database
> connection whenever you use the database. For example:
>
> Author.objects.using('otherdb').
be DRY...
Regards,
Johan
On Jun 16, 2:25 am, Russell Keith-Magee
wrote:
> On Tue, Jun 15, 2010 at 9:11 PM, johan de taeye
>
>
>
> wrote:
>
> >> You can't do this with a router; as you've noted, the router doesn't
> >> have any informatio
Folks,
Any thoughts on how I can implement the following elegantly in Django?
A first table contains let's say "product" records, which have a bunch
of attributes on which the admin pages provide filtering and sorting.
A second table contains "sales" records, which have a field referring
to the
Ben, Vince,
Thanks for the input!
It confirms what I suspected after a brief scan through the admin doc
and the code.
Johan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this g
I suspect you get this error because "level" is a reserved keyword in
many databases.
Try renaming the field.
Johan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send
Alex,
For this kind of "bulky transfer" the overhead created by the ORM will
always be a performance bottleneck: you continuously create and
destroy complex python objects.
Where/if possible, resort to raw SQL: you could eg use an execute_many
statement.
Expect a performance improvement of x5 -
An extra clause allows you to do this:
Project.objects.extra(where=['expected_start_date >
actual_start_date'])
On Feb 23, 8:16 am, shabda <[EMAIL PROTECTED]> wrote:
> I have a model like,
>
> class Project(models.Model):
> name = models.CharField()
> expected_start_date = models.DateF
For my frePPle project, I have been using py2exe to package a
standalone django application.
See here for my manage.py script:
http://frepple.svn.sourceforge.net/viewvc/frepple/trunk/contrib/installer/manage.py?revision=640&view=markup
Here's a patch for the django code to make also the django
David,
It's a very common requirement, and some people have run into this
before.
Have a look at this:
http://code.google.com/p/django-queue-service/
I doubt if this 'll be as robust and reliable as a real messaging
product, but for simple setups it'ld do the trick.
Johan
--~--~-
Marcio,
>>What is the status of this issue now? Anyone found a solution?
Yes, using py2exe for packaging a django application sure is possible.
Based on my py2exe+django experience with frePPLe [1]:
1) py2exe is an excellent way to package a django application in a
simple and straightforward w
This is very old issue in Django: see ticket
https://code.djangoproject.com/ticket/8280
I've attached the patch I'm already using for years to package my django
application with py2exe.
I don't understand why the core team continues to use the current
un-pythonic code to discover commands and
_fetch
AttributeError: 'NoneType' object has no attribute '_info'
Cheers
On Thursday, April 10, 2014 2:29:38 PM UTC+1, johan de taeye wrote:
This is very old issue in Django: see ticket
https://code.djangoproject.com/ticket/8280
I've attached the patch I'
I have a model that has a foreign key relation to a number of other objects.
When saving an instance of this model from the admin (or a ModelForm), I
see plenty of extra and redundant database calls.
For a single record it wouldn't make much of a difference, but when using
the same ModeForm to
b queries that is executed which is drastically reducing the
performance.
I believe I'll need a custom version of the ModelChoiceField class.
Op dinsdag 25 juli 2017 10:48:41 UTC+2 schreef James Schneider:
>
>
>
> On Jul 24, 2017 4:09 AM, "johan de taeye" > wrote:
&
17 matches
Mail list logo
