Reprise du message précédent :

peut-être que dans ce cas tu auras pu l'indiquer? Parce que ta question "comment je me branche dans Django", la page semble assez bien y répondre. Si t'as un problème plus précis que ça, comment je peux savoir ce qu'il est si tu n'as rien dit à son sujet?

Moins aggressive et plus originale que "je veux un champ custom et il y a une page qui m'explique comment on crée un champ custom"?

Non je le sais pas putain, comment tu veux que je le sache? Je sais pas comment tu fonctionnes précisément et django ne m'a jamais posé de problèmes personnellement, d'où je tirerais que "tu capte rien à la bibliothèque"? Ou à quoi dans la bibliothèque? D'autant plus quand j'ai tendance à pas te considérer comme étant con ou ayant des difficultés spécifiques, j'ai pas spécialement de raisons de penser ça et tes précédentes requêtes se placent assez largement dans un cadre "j'ai commencé à regarder ce truc il y a moins de 2 semaines donc je suis encore un peu paumé".

 
J'ai pas parlé de champ custom parce que je voulais pas fermer la discussion là-dessus. Là où je voulais fermer c'est sur le round-trip, parce qu'avec un round-trip t'as plus la possibilité d'utiliser 2 serveur web pour une base de données. C'est à la base de décider de manière atomique si l'ID est unique et de l'insérer ou de tout refuser.

Approche alternative au champ custom, un champ Integer ou CharField, avec le paramètre primary_key à True et avec en paramètre default un callable. Il me semble que dans ce cas là la fonction prend en paramètre l'instance en court de sauvegarde et doit retourner la valeur du champ.
 
NB : Note que c'est une piste, jamais testé encore.

justement j'ai regardé ça, mais il me faut de l'expertise, parce qu'en cas de collision sur une création, le système va faire sa requête, voir que l'ID existe, et transformer l'insert en update.
 
Y'a un paramètre dans save() pour forcer un insert, mais comment je récupère les choses en cas de collision ? j'ai pas trouvé le détail dans la doc.

Normalement le round-trip est pas gênant tant que tout est fait dans la même transaction et que le check initial est fait correctement (e.g. select for update), si on ignore le délai induit par le round-trip (si les serveurs sont sur des machines différentes et que le réseau est lent)

ça dépend du degré d'isolation des transactions.
 
dans mon cas c'est ok je pense, même en phantom read, mais dans le cas d'un update légitime ça doit pas toujours très bien se passer.

Hum j'ai du lire en diagonale, mais pourquoi dans ton callable tu ne fais pas :
1) Génération de l'ID
2) Une petite requête pour vérifier si l'ID est pas déjà prise sur ton modèle
3) GOTO 1 si c'est le cas
4) Sinon enjoy.

Note que le soucis de ta solution c'est que t'as aucune garantie que ton truc rentre pas dans une boucle potentiellement infinie si par manque de bol il tombe successivement sur un ensemble d'ID déjà prise.

Edit : En fait je ne vois pas où est ton soucis dans cette méthode

parce que ça me  
1) garantie pas que l'ID sera pas pris au moment de l'insert
2) ça sera re-vérifié au moment de l'insert
 
En fait je vois même pas pourquoi les gens font une requête à l'avance.

Ah c'est pas faux, j'avais zapé le cas des multiples insert en même temps.

Me semble qu'une IntegrityError est balancée, mais j'ai pas plus de précisions (et je sais pas dans quel état précis ça laisse ta transaction )

Comme d'hab.

Parce que si tu check pas, tu wedge ta transaction, donc faut utiliser des savepoints ou des sous-transactions et faut les rollbacker, je pense (et après faut décider de qui prend la décision de créer et rollbacker le dit savepoint, et faut savoir quelle sémantique tu prends pour une db n'ayant pas de sous-transactions, ou même de transactions tout court). Dans le cas général c'est pas une mauvaise décision (de faire un select for update suivi d'un insert si pas de résultats), mais dans le cas d'un insert sur un id crée manuellement le risque de collisions est non-trivial.

ça a l'air puissant les migrations auto de south

Ca fait au moins les changements basiques, ce qui est mieux que la solution livrée de base avec django, ie rien
 
Après éditer a la mano la migration c'est pas excessivement complexe non plus.

nan, mais là il faut en faire 3 en fait.
ajouter la colonne avec un null=True
ajouter un uuid à toutes les lignes existantes
virer le null=True de la colonne.

dites, j'ai un problème méga-stupide, comment on déclare un champ booléen avec true comme valeur par défaut ?

j'ai fait

mais dans la base derrière, y'a zéro dans la colonne.

Et si tu mets pas null=False? (c'est le défaut normalement)

nan, en fait c'est à cause du ModelForm derrière, il voit pas le champ arriver et il met False.
Je l'ai mis en  editable=False en attendant.
 
Mais la migration m'a mis la string 'True' dans la colonne pour les lignes existantes, j'ai été obligé de changer à la main

j'ai juste fait :  

et la deuxième ligne fait tout péter.

Du coup:

file_type, encoding = mimetypes.guess_type(map.attached_file.name)

j'ai relu la doc pour chercher le type de retour et j'ai pas vu ça
 
merci.

Un peu plus visible dans pydoc/help, il est au tout début du 2e paragraphe:

Le message d'erreur était pourtant explicite ...

j'avais pas compris d'où venait le tuple vu que je m'attendais à une chaine.

Drapal

http://blogs.jetbrains.com/pycharm [...] ense-type/

Edit :

Related, kinda

http://blogs.jetbrains.com/pycharm [...] ycon-2011/

http://www.revsys.com/django/cheatsheet/

Django 1.3 out http://www.djangoproject.com/weblog/2011/mar/23/13/

J'arrête pas de me faire griller sur cette news
En plus c'est un tag et un bump de version dans la doc et le setup.py

yeah \o/

Yo,

Comment j'attache proprement le request.user au request.POST?

request.POST.appendlist('user', request.user.id)

me parait pas térrible...

C'est surtout étrange de vouloir faire ça  

Chuis d'accord, un peu d'accord, tu peux expliquer le use case?

J'ai un modelForm basé sur un profile. J'ai mis le champs user dans Meta.exclude sinon le formulaire affiche logiquement un select avec la liste des utilisateurs.
 
Quand tu soumets le formulaire tu te tapes un “user.id constraint not null is not satisfied“ ou un truc du genre, vu que le field user n'est plus renseigné.
 
J'ai fais ça du coup.
 

forms.ProfileForm(data=request.POST, files=request.FILES, instance=request.user.get_profile())

Ptain c'est long le setUp tearDown de la DB à chaque test    
 
On a du PostgresSQL + PostGIS (Environ 2000 objets   ) , et ce que je teste n'utilise pas la db. Y'a pas moyen de dire au test runner de pas faire le setup de DB, juste pour mes tests?
Ou alors charger une SQLite en mémoire sans loader de fixtures?

drap'

Tu crées un 2e testcase sans les fixtures, pour les trucs qui touchent pas la db?

Elles sont autoloadées, faut que je bypasse la configuration vu que je touche pas à GIS. Je devrais pouvoir tester avec SQLite

Ah c'est juste le loaddata? Ptet les passer en fixtures explicites dans ce cas no?

Accessoirement, GeoDjango supporte SpatiaLite en GIS DB. Faut voir quelles sont les limitations, mais le GIS ne devrait pas empêcher des dbs sqlite.

Pour le dev django, vous faites plutôt du dev niveau projet (un repo avec un projet dedans et une app principale, potentiellement seule, ou même pas d'app du tout et tout directement dans le projet) ou plutôt du dev d'apps avec une sorte de projet générique servant surtout à tester une app ou un set d'app, mais qui ne correspondra pas nécessairement au projet (django) déployé?

Ce qu'on à sur mon projet c'est un set d'apps dans un seul répo. On à coupé en différentes section :
 
-core qui contient éssentiellement des apps qui définissent des models/tests/fields et admin custom. Orientées données donc.
-util qui contient des apps réutilisables et qui ne font pas nécessairement corps avec le reste du projet. E.g réutilisables avec d'autres projets.
 
Et enfin trois apps qui utilisent tout ça. Ils ont décidé de livrer chaque apps principales avec ses dépendances dans un .deb.
 
J'aurais préféré une app installable et versionnable. Mais c'est pas moi que j'décide.

De notre coté c'est un gros projet, avec pleins d'applications dedans, correspondant aux grandes "fonctions" du site. Maintenant c'est sans doute un cas à part, vu qu'il n'y a qu'un seul (gros) site web, donc pas vraiment de notion de réutilisation des applis pour d'autres sites.

 
'pouvez répéter la question ?
Faut vraiment que j'apprenne à parler l'informatique    
 
Un repo c'est quoi, un répertoire avec les sources ?
 
Une app principale ?
Edit : Ce sont les coeurs du traitement ou juste le "menu" qui articule le tout ?