Vous n'êtes pas identifié(e).
Bonjour à tous,
Je suis en train de m'amuser (enfin presque) à créer des modèles
dynamiques, créés à partir d'actions de l'utilisateur (upload de DBF).
ça marche bien tant que le serveur tourne sans recharge de la config,
mais après ils disparaissent, évidemment (pas leur table, mais leur
définition).
Donc voici quelques questions que je me pose :
Le plus malin (sic) serait-il de
- stocker les DBF puis de les retraiter à chaque rechargement (mais
c'est quand un rechargement côté code ? )
- écrire directement les définitions dans models.py. Dans ce cas,
y'a-t-il une fonction magique permettant de générer la définition objet
(et non SQL) d'un modèle ?
oui, je sais, c'est un peu fumeux tout ça, mais merci à ceux qui
pourront m'éclairer !
Hors ligne
Bonjour à tous,
Je suis en train de m'amuser (enfin presque) à créer des modèles
dynamiques, créés à partir d'actions de l'utilisateur (upload de DBF).
ça marche bien tant que le serveur tourne sans recharge de la config,
mais après ils disparaissent, évidemment (pas leur table, mais leur
définition).
Donc voici quelques questions que je me pose :
Le plus malin (sic) serait-il de
- stocker les DBF puis de les retraiter à chaque rechargement (mais
c'est quand un rechargement côté code ? )
- écrire directement les définitions dans models.py. Dans ce cas,
y'a-t-il une fonction magique permettant de générer la définition objet
(et non SQL) d'un modèle ?
oui, je sais, c'est un peu fumeux tout ça, mais merci à ceux qui
pourront m'éclairer !
Guillaume
Hors ligne
Salut,
C'est vrai que ça parait un poil bourrin le coup des modèles dynamiques, du
moins énoncé comme ça, je comprends pas ce qui peut te forcer à vouloir
utiliser ça, tu n'aurais pas pu t'en sortir avec un modèle générique et une
interface spécialisée pour accéder à tes variantes selon tes DBF ?
En tout cas en ce qui concerne le rechargement de l'appli. tu a des options
pour mod_python et fastcgi pour les forcer à reloader l'appli, selon que le
code change, ou bien périodiquement, ça dépend de ton module choisi.
Par contre c'est limite "overkill" vu que ça recharge vraiment toute l'appli,
en production c'est pas vraiment viable.
Le Wednesday 25 February 2009 17:37:07 Guillaume Sueur, vous avez écrit :
> Bonjour à tous,
>
> Je suis en train de m'amuser (enfin presque) à créer des modèles
> dynamiques, créés à partir d'actions de l'utilisateur (upload de DBF).
> ça marche bien tant que le serveur tourne sans recharge de la config,
> mais après ils disparaissent, évidemment (pas leur table, mais leur
> définition).
> Donc voici quelques questions que je me pose :
> Le plus malin (sic) serait-il de
> - stocker les DBF puis de les retraiter à chaque rechargement (mais
> c'est quand un rechargement côté code ? )
> - écrire directement les définitions dans models.py. Dans ce cas,
> y'a-t-il une fonction magique permettant de générer la définition objet
> (et non SQL) d'un modèle ?
>
> oui, je sais, c'est un peu fumeux tout ça, mais merci à ceux qui
> pourront m'éclairer !
>
> Guillaume
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
> ---------------------------------------------------------------------------
>------------ Orange vous informe que cet e-mail a ete controle par
> l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete
> detecte.
Hors ligne
Bonjour David,
j'ai voulu faire simple dans mes explications. En fait ce sont des
fichiers SIG (cartographiques) que je charge et que je gère avec geoDjango.
Bon, je l'ai fait bourrin... Je dumpe en texte mes modèles dans
models.py, et je fais un admin.register(leModele)
donc tant que ça ne redémarre pas, ça reste chargé par le admin.register
, et si apache/serveur/autre chose fait redémarrer django, tout est dans
models.py !!!
David Thenon a écrit :
> Salut,
>
> C'est vrai que ça parait un poil bourrin le coup des modèles dynamiques, du
> moins énoncé comme ça, je comprends pas ce qui peut te forcer à vouloir
> utiliser ça, tu n'aurais pas pu t'en sortir avec un modèle générique et une
> interface spécialisée pour accéder à tes variantes selon tes DBF ?
>
> En tout cas en ce qui concerne le rechargement de l'appli. tu a des options
> pour mod_python et fastcgi pour les forcer à reloader l'appli, selon que le
> code change, ou bien périodiquement, ça dépend de ton module choisi.
>
> Par contre c'est limite "overkill" vu que ça recharge vraiment toute l'appli,
> en production c'est pas vraiment viable.
>
>
> Le Wednesday 25 February 2009 17:37:07 Guillaume Sueur, vous avez écrit :
>> Bonjour à tous,
>>
>> Je suis en train de m'amuser (enfin presque) à créer des modèles
>> dynamiques, créés à partir d'actions de l'utilisateur (upload de DBF).
>> ça marche bien tant que le serveur tourne sans recharge de la config,
>> mais après ils disparaissent, évidemment (pas leur table, mais leur
>> définition).
>> Donc voici quelques questions que je me pose :
>> Le plus malin (sic) serait-il de
>> - stocker les DBF puis de les retraiter à chaque rechargement (mais
>> c'est quand un rechargement côté code ? )
>> - écrire directement les définitions dans models.py. Dans ce cas,
>> y'a-t-il une fonction magique permettant de générer la définition objet
>> (et non SQL) d'un modèle ?
>>
>> oui, je sais, c'est un peu fumeux tout ça, mais merci à ceux qui
>> pourront m'éclairer !
>>
>> Guillaume
>> _______________________________________________
>> django mailing list
>> django _AT_ lists.afpy.org
>> http://lists.afpy.org/mailman/listinfo/django
>> ---------------------------------------------------------------------------
>> ------------ Orange vous informe que cet e-mail a ete controle par
>> l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete
>> detecte.
>
>
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>
>
Hors ligne
Bien le bonjour,
Ecrire dans un fichier puis l'importer dynamiquement ne me semble pas etre
une bonne pratique du tout. Rien que d'un point de vue concurrence d'accès
ca risque de se planter rapidement.
Ca dépend combien de modèles tu génères dynamiquement, mais perso la
meilleur solution que je vois est de reloader à partir des tables en base de
données à chaque fois que Django doit recharger les modèles de ton
application de manière générale (arret/redémarrage du serveur etc.) Il me
semble qu'il y a un signal de lancé quand cela arrive (de tete je me rapelle
plus lequel).
Voilà, j'espère que ca aide un peu.
Cyril
2009/2/25 Guillaume Sueur <guillaume.sueur _AT_ neogeo-online.net>
> Bonjour à tous,
>
> Je suis en train de m'amuser (enfin presque) à créer des modèles
> dynamiques, créés à partir d'actions de l'utilisateur (upload de DBF).
> ça marche bien tant que le serveur tourne sans recharge de la config,
> mais après ils disparaissent, évidemment (pas leur table, mais leur
> définition).
> Donc voici quelques questions que je me pose :
> Le plus malin (sic) serait-il de
> - stocker les DBF puis de les retraiter à chaque rechargement (mais
> c'est quand un rechargement côté code ? )
> - écrire directement les définitions dans models.py. Dans ce cas,
> y'a-t-il une fonction magique permettant de générer la définition objet
> (et non SQL) d'un modèle ?
>
> oui, je sais, c'est un peu fumeux tout ça, mais merci à ceux qui
> pourront m'éclairer !
>
> --
> Guillaume
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>
Hors ligne
non, il y a deux étapes :
1. la création dynamique du modèle, avec un simple register. Mais ce
modèle est perdu après redémarrage
2. La déclaration dans models.py de ce modèle, mais models.py ne sera
rechargé qu'au redémarrage d'Apache (en étant en mod_python).
Donc le seul accès concurrentiel à gérer est celui des utilisateurs. Peu
sont appelés à charger de nouveau modèles. Mais ça peut crasher
quand-même si on n'y prend garde.
Cependant ton idée de reload m'intéresse aussi. Il y a quelque chose de
simple pour faire du reverse engineering de table -> modèle ?
Merci !
Guillaume
Cyril Doussin a écrit :
>
> Bien le bonjour,
>
> Ecrire dans un fichier puis l'importer dynamiquement ne me semble pas
> etre une bonne pratique du tout. Rien que d'un point de vue concurrence
> d'accès ca risque de se planter rapidement.
> Ca dépend combien de modèles tu génères dynamiquement, mais perso la
> meilleur solution que je vois est de reloader à partir des tables en
> base de données à chaque fois que Django doit recharger les modèles de
> ton application de manière générale (arret/redémarrage du serveur etc.)
> Il me semble qu'il y a un signal de lancé quand cela arrive (de tete je
> me rapelle plus lequel).
>
> Voilà, j'espère que ca aide un peu.
>
> Cyril
>
>
> 2009/2/25 Guillaume Sueur <guillaume.sueur _AT_ neogeo-online.net
> <mailto:guillaume.sueur _AT_ neogeo-online.net>>
>
> Bonjour à tous,
>
> Je suis en train de m'amuser (enfin presque) à créer des modèles
> dynamiques, créés à partir d'actions de l'utilisateur (upload de DBF).
> ça marche bien tant que le serveur tourne sans recharge de la config,
> mais après ils disparaissent, évidemment (pas leur table, mais leur
> définition).
> Donc voici quelques questions que je me pose :
> Le plus malin (sic) serait-il de
> - stocker les DBF puis de les retraiter à chaque rechargement
> (mais
> c'est quand un rechargement côté code ? )
> - écrire directement les définitions dans models.py. Dans ce cas,
> y'a-t-il une fonction magique permettant de générer la définition objet
> (et non SQL) d'un modèle ?
>
> oui, je sais, c'est un peu fumeux tout ça, mais merci à ceux qui
> pourront m'éclairer !
>
> --
> Guillaume
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org <mailto:django _AT_ lists.afpy.org>
> http://lists.afpy.org/mailman/listinfo/django
>
>
>
>
> --
>
> Cyril Doussin
> Freelance web developer
> cdoussin _AT_ gmail.com <mailto:cdoussin _AT_ gmail.com>
> http://cyril.doussin.name
> Twitter: http://twitter.com/cdoussin
>
> Project Fondue:
> http://projectfondue.com
> http://website-performance.org
> http://favicon-generator.org
-
Hors ligne
Le Wed, 25 Feb 2009 20:07:08 +0100,
Guillaume Sueur <no-reply _AT_ neogeo-online.net> a écrit :
> non, il y a deux étapes :
> 1. la création dynamique du modèle, avec un simple register. Mais ce
> modèle est perdu après redémarrage
> 2. La déclaration dans models.py de ce modèle, mais models.py ne sera
> rechargé qu'au redémarrage d'Apache (en étant en mod_python).
> Donc le seul accès concurrentiel à gérer est celui des utilisateurs.
> Peu sont appelés à charger de nouveau modèles. Mais ça peut crasher
> quand-même si on n'y prend garde.
>
> Cependant ton idée de reload m'intéresse aussi. Il y a quelque chose
> de simple pour faire du reverse engineering de table -> modèle ?
Bonjour,
La commande ./manage.py inspectdb permet précisément de "reverser"
une base de donnée. Regarder le fichier /django/core/management/commands/inspectdb.py, vous devriez
trouver des pistes.
Stéphane.
(...)
Hors ligne
en effet ! merci !
Guillaume
Stephane Bunel a écrit :
> Le Wed, 25 Feb 2009 20:07:08 +0100,
> Guillaume Sueur <no-reply _AT_ neogeo-online.net> a écrit :
>
>> non, il y a deux étapes :
>> 1. la création dynamique du modèle, avec un simple register. Mais ce
>> modèle est perdu après redémarrage
>> 2. La déclaration dans models.py de ce modèle, mais models.py ne sera
>> rechargé qu'au redémarrage d'Apache (en étant en mod_python).
>> Donc le seul accès concurrentiel à gérer est celui des utilisateurs.
>> Peu sont appelés à charger de nouveau modèles. Mais ça peut crasher
>> quand-même si on n'y prend garde.
>>
>> Cependant ton idée de reload m'intéresse aussi. Il y a quelque chose
>> de simple pour faire du reverse engineering de table -> modèle ?
>
> Bonjour,
>
> La commande ./manage.py inspectdb permet précisément de "reverser"
> une base de donnée. Regarder le fichier /django/core/management/commands/inspectdb.py, vous devriez
> trouver des pistes.
>
> Stéphane.
>
> (...)
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>
>
Hors ligne
Autre question dans la même veine, puisque les retours sont bons...
lors de la manipulation d'un modele quelconque dans le code, peut-on
retrouver les noms des champs et leurs types ?
Merci !
Guillaume
Guillaume Sueur a écrit :
> en effet ! merci !
>
> Guillaume
>
> Stephane Bunel a écrit :
>> Le Wed, 25 Feb 2009 20:07:08 +0100,
>> Guillaume Sueur <no-reply _AT_ neogeo-online.net> a écrit :
>>
>>> non, il y a deux étapes :
>>> 1. la création dynamique du modèle, avec un simple register. Mais ce
>>> modèle est perdu après redémarrage
>>> 2. La déclaration dans models.py de ce modèle, mais models.py ne sera
>>> rechargé qu'au redémarrage d'Apache (en étant en mod_python).
>>> Donc le seul accès concurrentiel à gérer est celui des utilisateurs.
>>> Peu sont appelés à charger de nouveau modèles. Mais ça peut crasher
>>> quand-même si on n'y prend garde.
>>>
>>> Cependant ton idée de reload m'intéresse aussi. Il y a quelque chose
>>> de simple pour faire du reverse engineering de table -> modèle ?
>> Bonjour,
>>
>> La commande ./manage.py inspectdb permet précisément de "reverser"
>> une base de donnée. Regarder le fichier /django/core/management/commands/inspectdb.py, vous devriez
>> trouver des pistes.
>>
>> Stéphane.
>>
>> (...)
>> _______________________________________________
>> django mailing list
>> django _AT_ lists.afpy.org
>> http://lists.afpy.org/mailman/listinfo/django
>>
>>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>
>
Hors ligne