Reprise du message précédent :
Perso les deux seules fois ou j'ai eu de gros problèmes de fuites mémoires par évident à trouver, j'utilisais le module hotshot et kcachegrind pour visualiser la sortie.

Ouais, là j'utilise un framework maison pour des traitements batch, y'a pas grand chose de prévu pour monitorer la mémoire, et j'ai régulièrement des problèmes.
edit:  ah oui, j'avais déjà essayé objgraph, le truc qui m'avait paru le plus rapidement praticable.

dites, comment je mets l'utilisateur courant dans le champ 'user' d'un modèle que je suis en train de créer dans une view ?
 
j'ai tenté :

form = MapForm(post, files, initial={'user':request.user})
        if form.is_valid():
            form.clean()
            map = form.save()

mais la map n'a pas d'user après le save()
 
j'ai tenté :

form = MapForm(post, files)
    if request.user.is_authenticated():
        form.user = request.user
    if form.is_valid():
        form.clean()
        map = form.save()

toujours pas d'user dans la map
 
du coup je set le user dans la map directement et je re-sauve, mais bof

form = MapForm(post, files, instance=request.user)

Je pense.

Shinu > je pense pas tu dois passer une instance de Map.
 
dites, comment je peux utiliser la vue logout de là, mais en interdisant de l'appeler par GET (POST obligatoire) ?
https://docs.djangoproject.com/en/d [...] auth.views
 
je trouve pas de décorateur post_only
je saurai pas l'appliquer à une vue par défaut
je trouve pas de syntaxe que je puisse utiliser pour ça dans url.py
 
du coup je vois pas de moyen plus élégant que d'écrire une vue qui va rappeler celle par défaut

un wrapper dans l'urls.py ?
 
 
edit :
 

je comprends pas comment ça va empêcher le GET ça.

django.views.decorators.http.require_POST

Un décorateur, c'est rien de plus qu'une HoF 1:1. Ça prend une fonction en entrée, ça renvoie une vue en sortie. Il y a juste une syntaxe un peu plus claire (parce que postfixe) pour aller avec def. La seule partie potentiellement tricky c'est quand il prend des paramètres (dans ce cas t'as une fonction qui prend des paramètres et renvoie une fonction qui prend une fonction et renvoie une fonction).

from django.contrib.auth.views import logout
from django.views.decorators.http import require_POST
# [...]
    (r'^accounts/logout/$', require_POST(logout)),

 merci.

Comme précisé juste au dessus, en mettant ton décorateur a cet endroit.

T'façon j'aime pas les forms.

Petit post pour ceusse qui utilisent de gros dictionnaires (plusieurs millions d'éléments). D'habitude, c'est pas forcément très recommandé vu ce que ça bouffe en mémoire, vive les générateurs. Mais parfois on en a quand même besoin.

J'ai fait quelques tests de kyotocabinet, une "base de données" clef-valeur threadsafe qui peut peut s'appuyer sur des fichiers ou résider en RAM comme cache. Elle peut avoir une structure de hashtable ou d'arbre ordonné en fonction des besoins.

Comparaison entre kctree et les dict() de Python:

from kyotocabinet import *
import sys
import os
import re
import time
 
def memoryusage():
    for line in open("/proc/self/status" ):
        line = line.rstrip()
        if line.startswith("VmRSS:" ):
            line = re.sub(r".*:\s*(\d+).*", r"\1", line)
            return float(line) / 1024
    return -1
 
musage = memoryusage()
rnum = 1000000
if len(sys.argv) > 1:
    rnum = int(sys.argv[1])
 
if len(sys.argv) > 2:
    hash = DB()
    if not hash.open(sys.argv[2], DB.OWRITER | DB.OCREATE | DB.OTRUNCATE):
        raise RuntimeError(hash.error())
else:
    print "Using Python dict()"
    hash = {}
 
stime = time.time()
print "Insert %d items" % rnum
for i in xrange(0, rnum):
    key = "%08d" % i
    value = (key, 3.1416, i) 
    hash[key] = value
    if i % 1000000 == 0:
        ctime = time.time() 
    print "Time: %.3f sec." % (ctime - stime), i
        stime = ctime
etime = time.time()
print "Time: %.3f sec." % (etime - stime)
 
print "Retrieve %d items" % rnum
stime = time.time()
for i in xrange(0, rnum):
    key = "%08d" % i
    value = hash.get(key)
    if value != str((key, 3.1416, i)):
        raise ValueError("Retrieved and inserted values do not match !" ) 
    if i % 1000000 == 0:
        ctime = time.time() 
    print "Time: %.3f sec." % (ctime - stime), i
        stime = ctime
etime = time.time()
print "Time: %.3f sec." % (etime - stime)
 
print "Count: %s" % len(hash)
print "Usage: %.3f MB" % (memoryusage() - musage)

Tests sur un Core2Duo 2.14GHz, 2Go de RAM, Linux 2.6.32 32 bits

Le fichier db.kct fait 534 Mo.
Sur ma machine, non seulement la RAM utilisée par KC est constante, mais sur un grand nombre d'items il est du même ordre de grandeur niveau rapidité. De plus il a le bon goût d'adopter la syntaxe des dictionnaires Python, ce qui rend le portage quasi immédiat.
Les tests avec la structure hash donnent ça:

C'est bcp plus lent mais la RAM utilisée est encore bcp plus faible.

Bref, je trouve cette lib pas mal du tout, ça peut aider dans certains cas par rapport à des techniques de sérialisation sur disque qui seront bcp plus lentes et lourdes à mettre en oeuvre. Il y a aussi un serveur HTTP si besoin, mais évidemment, on n'obtient pas les mêmes performances. Le regret que j'ai est que l'API Python ne semble pas inclure la possibilité de "tuner" la base comme le permet l'API C++. Je me demande bien pourquoi.

Faudrait aussi tester avec un sqlite in-memory, un redis et un tokyo cabinet pour faire bonne mesure. Au minimum.

Oui mais le in memory ne m'intéresse pas tellement, en fait. Mon problème au départ, c'est d'éviter de voir la mémoire exploser sur des millions d'enregistrements, et éventuellement de pouvoir reprendre un traitement en cours après interruption involontaire.
J'ai pas fait le test avec sqlite, mais les gus de Google (Jeff Dean et son pote indien) l'on fait, et sauf quand les éléments sont gros il est assez loin derrière. Il est possible aussi qu'il rattrape son retard pour les très gros volumes (disons 10⁸ ou plus), je n'ai pas fait le test. Mais un des intérêts majeurs de ce truc, c'est que tu codes exactement comme si c'était des dict, l'écriture sur disque se fait de façon transparente. Il n'y a oas de notion de relationnel, rien de ce que permet SQLite.
Tokyo cabinet est le prédécesseur de kyoto cab, il est apparemment plus performant, mais moins avancé dans les fonctionnalités, et parait-il plus chiant à builder.
LevelDB est très prometteur, mais pour l'instant, c'est une lib C des plus basiques, il n'y a pas de binding Python particulier.

Je me mets tout doucement aux class based views.
 
Mais si vous avez une page avec plusieurs forms de plusieurs models, vous savez comment procéder ? Une FormView ou UpdateView ne gèrent qu'une seule form non ? Faut faire une TemplateView toute simple avec de la gestion de forme dedans ? Mais dans quelle fonction on les gère etc ...

dites les jeunes, une autre question de n00b aussi : est-ce que je skin les forms de login/logout d'admin et j'envoie mes utilisateurs normaux dessus ou est-ce que je fais les miens ?
 
pour l'instant j'ai fait les miens, mais je me demande.

Attention avant/après le déploiement, si tu finis par l'utiliser en prod, ils sont mis çà en place dans ma boite précédente et il semble y avoir quelques problèmes de stabilité... Pas plus d'infos là dessus par contre.
 
@nraynaud : J'hésite toujours aussi. Au final je me retrouve souvent à faire les miens.

J'ai toujours fait les miens aussi.

ok, merci, je reste comme ça alors

Ah, ce serait possible d'avoir plus de précisions ? Merci.

J'essaierai d'avoir plus d'infos à l'occaz d'un pot avec mes anciens collègues, mais là non, j'ai pas plus d'infos.

dites, y'a moyen d'avoir des champs optionnels dans un ModelForm ? je veux que lors du submit on accepte le form que mon champ soit là ou non (y'a une valeur par défaut).
 
quand j'utilise exclude, mon champ est pas pris en compte, et quand je laisse le champ dans le form, il refuse les submits où il apparaît pas.

Faut overrider le champ dans le ModelForm et passer `require=False` (à la base ça tape dans le blank du model field, modelform.field.required = not model.field.blank)

Par contre dans ce cas t'es obligé de porter tous les attributs du Model au ModelForm (genre help_text ou max_length).

ok, mon champ est actuellement null=True, c'est donc pas converti automatiquement en require=False ? (sinon je serai pas là à demander j'imagine)
 
je pense que dans mon cas c'est pas con de répéter tous les champs dans le form, parce qu'il y en a certains que je pourrai oublier et spiller côté user.

Non, faut mettre blank=True, qui lui sera converti en required=False

Bordel, ça devait etre ça mon pb.

dites, si j'ai une machine (virtuelle) neuve à poil dans la main droite et le git avec mon projet django dans la gauche, c'est quoi la méthode la plus rapide pour que le projet soit servi par la machine ?

UP  
 
là puppet ça me casse les couilles

dites, j'ai des cookies que je manipule à la fois côté JS et côté serveur, et je me retrouve parfois avec le cookie en double (2 fois le même nom avec des valeur différente dans les Requests).
 
est-ce que HttpResponse.set_cookie() ajoute le cookie ou le remplace s'il existe ?

Il n'y a pas de différence entre ces opérations, à ma connaissance t'as un seul header de réponse Set-Cookie qui est utilisé pour C, U et D.

'tain je sais pas ce que je fous, mais il doublonne ce con.

truc à la con genre encoding ou je sais pas quoi?

c'était le path, il faut mettre / à tout le monde, le plugin jQuery le faisait pas.

Ah oui effectivement

toujours fait les miens personnellement, notamment à cause du chemin des templates qui correspond pas à mes « conventions » et dont je peux me passer.
(salut à tous)

ok, merci.  
Avant de poser la question j'avais fait les miens (parce que j'avais pas encore lu la doc sur l'admin) et 2 autres personnes font les leurs je pense le cas est résolu.

dites, dans mon model j'ai des champs de texte généralement court (titre de pages, nom des gens etc.), mais dont j'ai absolument pas envie de limiter la longueur de manière arbitraire (entre autre parce que j'ai pas de critère pour le faire) y'a autre chose que CharField ou TextField ?
 
J'en ai marre de ces champs limités en longueur, on se croirait dans les années 80 avec des flat files

Bah en même temps, django reste limité par ce qui est en dessous, tu peux toujours coller des tailles vachement hautes mais derrière tu risques de te taper les limites d'implé des dbs (VARCHAR sous Oracle c'est 4000 caractères max).

Mais pourquoi tu utilises pas un textfield justement? Il n'y a pas de limites dessus, c'est fait pour ça non? (je présume que TextField mappe sur le type text, sinon je vois pas d'intérêt).

D'ailleurs sous Postgres, VARCHAR et TEXT ont les mêmes perfs, donc tu peux mettre du TEXT partout si ça te chante (et tu changes le widget pour avoir des charfields en admin au lieu de textarea partout)

edit: et dans SQLite, VARCHAR devient TEXT, il n'y a pas de type VARCHAR ou CHAR.

Le truc c'est qu'à ma connaissance le coupable c'est pas django, mais les DBMS qui sont derrières. La plupart, comme PostgreSQL ou MySQL demandent une taille fixe pour le type char de base.

Par contre, une note intéressante sur PostGreSQL par exemple c'est qu'il n'y a pas de différence de performance entre les différents types. http://www.postgresql.org/docs/8.2 [...] acter.html  ( voir le "tip" ), du coup autant utiliser un TextField par exemple.

Edit : FFS burned by Mask !

j'achète l'analyse.
 
J'ai juste besoin de renforcement social

Tu peux même aliaser TextField(widget=whatever_the_char_widget_is) en CharField, comme ça tu utilises juste TextField ou CharField selon ce que tu veux en widget par défaut/dans ton admin, et dans tous les cas c'est stocké en text sans limite de taille.

J'ai toujours pensé que char/varchar pouvait être plus efficace pq tu stockes des records en fixed-length alors qu'avec text t'as (potentiellement) une indirection, mais si c'est pas le cas (pour postgres et sqlite, les autres je m'en bat) en fait c'est se faire chier pour rien, text FTW.