Reprise du message précédent :

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.

Fun stuff: ils ont ajouté des trucs à ce texte dans toutes les révisions de la doc, dans la doc 9.1 il est expliqué que character(n) est généralement plus lent que les 2 autres

Je note également, il semble possible d'utiliser character varying (et ptet aussi varchar) sans donner une taille, en tout cas dans postgres (et sqlite, qui regarde juste si t'as "text", "char" ou "clob" dans ton type il se pose même pas la question de la spec taille). Je sais pas ce que ça donne ailleurs.

postgres est nray-compilant

à mon avis c'est surtout que t'as surtout une indirection dans *tous* les cas.

Apparemment, sql server est un peu plus merdique mais tu peux quand même te démerder avec:
 

• TEXT est toujours stocké out-of-row et lent, il a été déprécié
• VARCHAR(n) et NVARCHAR(n) sont limités à 8k (apparemment pour 2000 et plus vieux, toute la row doit tenir dans 8k), pour NVARCHAR ça veut dire 4000 chars
• MS a ajouté VARCHAR(MAX) et NVARCHAR(MAX), qui sont les versions pas stupides: si elles tiennent dans la row elles sont stockées inline (comme VARCHAR(n)), si elles overflow elles sont stockées avec une indirection, et limitées à 2Go de données comme TEXT et CHARACTER VARYING sous pg. Faudrait voir sur quoi CharField et TextField mappent quand tu utilises django avec sql server.

Bah non ce serait débile, si ta chaîne est courte autant la stocker inline. C'est ce que fait VARCHAR(MAX) sous SQL Server, et dans la mesure où postgres change de comportement au dessus de 126b, je présume que c'est également le cas. Sauf que la limite pour dégager la valeur de la row est probablement plus haute.

Cf doc:

clairement les chaînes courtes sont stockées dans les rows, sinon la partie en gras n'aurait pas de sens.

je vois pas comment tu peux avoir des rows de longueur fixes dans ce cas.

T'as pas de rows de longueur fixe, ou alors tes champs text/varchar ont une taille allouée égale à leur max inline si pas de taille spécifiée. Problem fucking solved.

Par contre tu peux avoir des problèmes d'index, je te préviens tout de suite, dans postgres b-tree pête si les champs sont trop grands, faut passer à un autre type d'index (genre hash).

bon, stu veux (je doute, mais la flemme de rentrer là-dedans)
 
sinon, dans south, j'ajoute une colonne, mais en même temps je veux migrer des data dedans, il faut que je fasse une schemamigration suivie d'une datamigration ou je peux tout mettre dans une seule migration ?

Hum, je pense que le models auquel tu vas accéder dans ta schemamigration via le orm.* sera encore l'ancien schéma, du coup ça risque de péter si tu tapes sur de nouveaux champs (après tu peux toujours faire le gros dégeu et importer directement ton model, mais c'est très sale).
 
Du coup :
- schemamigration
- puis datamigration
 
C'est pas pour la ligne de commande en plus que ça prend à faire !

ok, merci

c'était plus pour l'atomicité du changement en fait.

Si tu donnes que la moitié des infos aussi
 
Du coup j'imagine qu'en encapsulant tout dans une transaction ça doit être possible, mais j'avoue qu'en utilisant south je ne sais pas trop comment tu peux faire, j'ai jamais eu de migration suffisamment critique pour me pencher sur ce problème.

non, c'est pas critique, c'est juste que j'ajoute une colonne et que je la peuple à partir d'une autre colonne (j'ai une autre colonne qui contient du JSON et je vais en extraire une propriété en colonne)
donc je pensais logique d'encapsuler en un seul endroit l'ajout de la colonne et son peuplement. C'est plus de la politique d'organisation du code.

le problème c'est que quand le champ est blank, il utilise pas le default ce con
 
dans mon modèle j'ai :  

basemap = models.TextField(choices=BASEMAPS, default="roadmap", blank=True)

 
dont j'espère vaguement que ça veut dire : "ne force pas la présence de roadmap dans le ModelForm et si personne ne te file de basemap dans le formulaire, mets roadmap" mais en vrai ça met le champ à chaîne vide

bordel :

basemap = models.TextField(choices=BASEMAPS, default="roadmap" )

class MapForm(ModelForm):
    class Meta:
        model = Map
 
    def __init__(self, *args, **kwargs):
        super(MapForm, self).__init__(*args, **kwargs)
        self.fields['basemap'].required = False

m'envoie chaine vide dans la base

edit: et avec toute la réflexion dans tous les sens je sais même pas où mettre un point d'arrêt pour voir si c'est le form ou le model qui fait pas ce que je veux

y'a pas d'exception pour le 403 ?

dites, c'est moi ou y'a pas le paramètre "next" dans le AuthenticationForm par défaut ?  
 
du coup toute la chaine de login par défaut gère le "next" sauf le formulaire
 
(sinon, je me sens un peu seul sur mon topac, django c'est pas sensé être le truc trendy ? )

Des news sur le passage à Python 3 :
 
http://groups.google.com/group/dja [...] 685ad0302#
 
@nraynaud : Clairement l'activité sur les sites FR pour Django est assez limitée. Par contre je trouve qu'on trouve facilement de la doc/examples sur les sites UK, que ce soit des blogs ou sur stackoverflow.

Pour ceuxe qui utilisent les forms django mais ont besoin de plus de contrôle sur le rendu précis: floppyforms.
 
À voir aussi: Django Uni-Form, qui utilise uni-form pour faire de jolis rendus de formulaires à base de divs, à la place des paragraphes ou tables fournis dans Django.

hep, y'a un endroit "django-esque" pour mettre les décorateurs de vue ?

Pas à ma connaissance.  
 
Perso je les mets dans un fichiers decorators.py dans l'appli concerné si c'est spécifique à une appli, sinon en général dans mon arbo j'ai un module Python qui regroupe tous les trucs un peu utilitaires et co, je le met dedans si c'est global à toutes les applis.

Guide assez complet sur les fields et widgets custom dans les forms django:
http://tothinkornottothink.com/pos [...] -in-detail

Excellent

Drap'

quelqu'un a déjà joué avec un système noSQL orienté document et django ?
Il faut quand même une base traditionnelle pour les utilisateurs ?

Les Generic Views sur Django, vous les utilisez un peu, beaucoup, pas du tout ?
Je suis en train de me pencher sérieusement sur le bouzin depuis leur refactoring. Le truc qui m'ennuie un peu en fait c'est qu'on a souvent besoin de pleins de petits trucs particuliers dès qu'un projet grossi, un simple listing d'object suffit plus. Et si y a pleins de façons de "particulariser" ces Generic Views, au final j'ai un peu l'impression qu'on se retrouve à refaire la même chose que si tu passais via une vue classique...

moi je les utilise un peu, mais souvent complètement custo.

Tu parles des class based views ?
 
Moi j'essaye de les utiliser autant que possible ...

Je parle de ça : https://docs.djangoproject.com/en/1 [...] sed-views/ oui

Oui oui, j'avais cru lire qu'il était recommandé de ne plus passer par des fonctions.

Comme je suis discipliné et qu'après toutes ces années de programmation, j'ai appris qu'il était bon de suivre les évolutions et ne pas rester sur "ce qui marche" et "qui fait très bien ce que j'ai envie de faire", ben je me force avec les Class Based View.

C'est franchement pas mal d'un certain point de vu. Mais c'est sur que pour un code simple avec un seul développeur, ça peut être assez lourd et chiant.

dites, comment je peux affecter un fichier déjà sur le serveur à un FileField ?
 
Le fichier a été téléchargé au bon endroit lors de la preview, mais je vais affecter le champs de l'entité que quand l'utilisateur a confirmé.

Hello,
 
J'essaye de créer une applis pour gérer nos stocks de matériel, au service informatique de là où je bosse.
 
Donc j'ai plusieurs tables de prévues (je ne vais parler ici que de ce qui m'intéresse, bien entendu).
 
Voici les tables :
 
HardwareInfoField
Contient la liste des caractéristiques qui pourront être demandées ou non en fonction du matériel.
 
Exemple :

 
-------------------------------------------------------------------
 
HardwareType
Contient la liste des types de matériel, avec les ID des différentes caractéristiques à associer au type
 
Exemple :

--------------------------------------------------------------------
 
HardwareBrand
Contient la liste des marques.
 
Exemple :

---------------------------------------------------------------------
 
HardwareReference
Contient la liste des références produits.
 
Exemple :

---------------------------------------------------------------------
 
Maintenant il me faut une table qui me permet d'enregistrer effectivement chaque matériel.
 
Si je réceptionne un nouveau PC Portable HP 4530s par exemple, je dois pouvoir l'enregistrer, et donc avoir une table qui stocke la référence, ainsi que les valeurs des différents champs "HardwareInfoField" associés.
 
En gros il me faut une table qui stocke chaque matériel (Hardware). Avec une ForeignKey sur une référence produit.
 
Puis une table qui fait le lien entre un ID de Hardware, un ID de HardwareInfoField, et la valeur entrée par l'user.
 
Mais j'ai du mal à comprendre comment faire ça proprement dans les modèles.
 
Pour le moment j'ai ça :
 

class HardwareInfoField(models.Model):
    name = ...
    type = ...
    extra = ...
 
class HardwareType(models.Model):
    name = ...
    info_fields = ...
 
class HardwareBrand(models.Model):
    name = ...
 
class HardwareReference(models.Model):
    name = ...
    brand = models.ForeignKey(HardwareBrand)
    type = models.ForeignKey(HardwareType)
 
class Hardware(models.Model):
    reference = models.ForeignKey(HardwareReference)

 
Et je bute à ce niveau là.
 
Si quelqu'un à une piste à me donner sur la manière de procéder ...

Pour la suite j'imagine un truc du genre :
 

class HardwareInfoValue(models.Model):
    hardware = models.ForeignKey(Hardware)
    info_field = models.ForeignKey(HardwareInfoField)
    value = ...

 
Ca semble correct comme manière de procéder ?

Alex Gaynor: Why I hate the Django ORM (slides only)

Je pense que ces remarques sont venues à toutes personnes ayant utilisé Django et son ORM pour faire une appli un peu plus évoluée qu'un blog. Faire un SELECT SUM/MIN/MAX .... GROUP BY c'est juste pas intuitif du tout la syntaxe de l'ORM
 
Mais après le constat, il propose quoi ? J'ai pas vu passer de messages sur une refonte des fonctions "avancées" de l'ORM sur le groupe django-dev...

Je sais pas (il en parlait ptet en dehors des slides, ou bien alors c'est juste une critique d'un "open problem" ), mais il montre au moins le code équivalent dans SQLAlchemy, chez qui les références sur des champs sont beaucoup plus régulières (c'est toujours la même syntaxe)

dites, actuellement, j'ai des virtualHosts PHP configurés comme ça :

 
comment je peux configurer mod_wsgi (ou peut-être autre chose, je suis pas raciste)  
pour pointer sur /var/www/%0/current/mondjango  
?

Exemple d'un vhost wsgi à moi si ça peut t'aider :
 

 
Faudrait que je protège mieux mon répertoire apache et son arbo Mais c'est juste pour du loisir
 
contenu de mon django.wsgi  
 

 
justement, je veux mettre une variable qui contienne le FQN du site à la place de <monsite> dans la directive WSGIScriptAlias

attention, c'est super-débile :
y'a juste un handler de base qui s'appelle wsgi-script (il faut ajouter le droit d'execCGI avec), du coup c'est pas la peine d'aller chercher dans la conf de mod_wsgi, c'est de la conf apache de base.
 
J'ai juste mis ça dans un .htaccess :

 
Je le mets ici parce que c'est tellement con que c'est difficile à trouver dans la doc (je l'ai vu en passant dans un exemple).