Quel est le meilleur moyen d'accéder à des procédures stockées dans l'ORM de Django

Je suis en train de concevoir une assez complexe de base de données, et de savoir que certaines de mes questions seront loin en dehors de la portée de l'ORM de Django. Quelqu'un a intégré SP avec l'ORM de Django avec succès? Si oui, quel SGBDR et comment avez-vous fait?

InformationsquelleAutor kkubasik | 2009-04-30
  1. 22

    Nous (musicpictures.com /eviscape.com) a écrit que django extrait mais ce n'est pas toute l'histoire (en fait, ce code a été testé uniquement sur Oracle à l'époque).

    Procédures stockées sens lorsque vous souhaitez réutiliser essayé et testé SP code, ou lorsque l'un SP appel sera plus rapide que de multiples appels à la base de données - ou lorsque la sécurité exige modéré accès à la base de données - ou lorsque les requêtes sont très compliquées ou plusieurs étapes. Nous sommes à l'aide d'un modèle hybride/SP approche à la fois contre Oracle et les bases de données Postgres.

    L'astuce est de le rendre facile à utiliser et à le garder "django", comme. Nous utilisons un make_instance fonction qui prend la suite de curseur et de créer des instances d'un modèle peuplée à partir du curseur. C'est bien parce que le curseur peut-retour des champs supplémentaires. Vous pouvez ensuite utiliser ces instances dans votre code /templates comme normal django objets de modèle.

    def make_instance(instance, values):
    '''
    Copied from eviscape.com

    generates an instance for dict data coming from an sp

    expects:
        instance - empty instance of the model to generate
        values -   dictionary from a stored procedure with keys that are named like the
                   model's attributes
    use like:
        evis = InstanceGenerator(Evis(), evis_dict_from_SP)

    >>> make_instance(Evis(), {'evi_id': '007', 'evi_subject': 'J. Bond, Architect'})
    <Evis: J. Bond, Architect>

    '''
    attributes = filter(lambda x: not x.startswith('_'), instance.__dict__.keys())

    for a in attributes:
        try:
            # field names from oracle sp are UPPER CASE
            # we want to put PIC_ID in pic_id etc.
            setattr(instance, a, values[a.upper()])
            del values[a.upper()]
        except:
            pass

    #add any values that are not in the model as well
    for v in values.keys():
        setattr(instance, v, values[v])
        #print 'setting %s to %s' % (v, values[v])

    return instance

    # L'utiliser comme ceci: 

    pictures = [make_instance(Pictures(), item) for item in picture_dict]

    # Et voici quelques fonctions utiles:

    def call_an_sp(self, var):
    cursor = connection.cursor()
    cursor.callproc("fn_sp_name", (var,))
    return self.fn_generic(cursor)


def fn_generic(self, cursor):
    msg = cursor.fetchone()[0]
    cursor.execute('FETCH ALL IN "%s"' % msg)
    thing = create_dict_from_cursor(cursor)
    cursor.close()
    return thing

def create_dict_from_cursor(cursor):
    rows = cursor.fetchall()
    # DEBUG settings (used to) affect what gets returned. 
    if DEBUG:
        desc = [item[0] for item in cursor.cursor.description]
    else:
        desc = [item[0] for item in cursor.description]
    return [dict(zip(desc, item)) for item in rows]

    acclamations, Simon.

    • Pourquoi avez-vous fermer le curseur dans fn_generic?
    • Je travaille sur un immense système avec une base de données est accessible par de multiples applications, en c++, python, certains perl, php, web sont basés, beaucoup ne le sont pas. J'aime quand la logique d'entreprise est dans le domaine SPs, car elle signifie que la logique est la même dans tous les implémentations, et dans notre cas, au moins, rend la maintenance plus facile.
    • j'ai trouvé ce commentaire par russ magee: "Nous avons expressément évité d'ajouter évident SQL comme caractéristiques de l'ORM de Django, car à la fin de la journée, nous ne sommes pas en train de remplacer SQL - nous essayons simplement de fournir un moyen pratique d'exprimer des requêtes simples. Il est entièrement attend de vous que vous reviendra à seulement appel SQL brut pour les cas complexes"
    InformationsquelleAutor
  2. 16

    Vous devez utiliser l'utilitaire de connexion dans Django:

    from django.db import connection

cursor = connection.cursor()
cursor.execute("SQL STATEMENT CAN BE ANYTHING")

    ensuite, vous pouvez récupérer les données:

    cursor.fetchone()

    ou:

    cursor.fetchall()

    Plus d'infos ici: http://docs.djangoproject.com/en/dev/topics/db/sql/

    InformationsquelleAutor igorgue
  3. 4

    Il y en est un bon exemple :
    https://djangosnippets.org/snippets/118/

    from django.db import connection


cursor = connection.cursor()
ret = cursor.callproc("MY_UTIL.LOG_MESSAGE", (control_in, message_in))# calls PROCEDURE named LOG_MESSAGE which resides in MY_UTIL Package
cursor.close()
    InformationsquelleAutor Hemant
  4. 2

    Si vous voulez regarder un réel projet en cours d'exécution qui utilise SP, découvrez minibooks. Une bonne partie de SQL personnalisée et utilise Postgres pl/pgsql pour SP. Je pense qu'ils vont supprimer le SP finalement, si (justification dans trac billet 92).

    InformationsquelleAutor Van Gale
  5. 0

    Ne pas.

    Au sérieux.

    Déplacer la procédure stockée logique dans votre modèle où il appartient.

    Mettre un peu de code dans Django et un peu de code dans la base de données est un entretien cauchemar. J'ai passé trop de mes 30 ans, IL tente de nettoyer ce genre de mess.

    • Ce qu'il demande est à propos de l'intégration de l'ORM avec l'accord SPs. Ce n'est probablement pas possible, et l'utilisation de procédures stockées probablement vous oblige à accéder simplement à django.db.connexion directement, comme dans les autres réponses, mais il serait intéressant si vous pouviez déplacer automatiquement les requêtes communes de l'ORM fait dans des procédures stockées, pour enregistrer sur la génération de requêtes temps, et de le faire de manière transparente, comme une optimisation. Il ne fonctionne pas sur toutes les bases de données, et le gain de performance n'est probablement pas la peine, mais il serait amusant de les étudier.
    • il leur demande est à propos de l'intégration de l'ORM avec l'accord SPs." Compris. D'où ma réponse. SP fragment de la logique de l'application entre la bonne application du code et la base de données. Ils créent souvent plus de problèmes qu'ils en résolvent. Je pense que les SP ne sont pas utiles en toutes circonstances et ne doit pas être utilisé.
    • Je pense que vous avez mal compris la remarque que j'ai faite. Je parle d'un imaginaire/l'avenir de l'ORM de Django. Les procédures stockées ne seront pas écrites par les développeurs. Cette ORM dynamiquement/de manière transparente convertir couramment exécutées ORM requêtes dans des procédures stockées, de sorte qu'il peut enregistrer sur une chaîne SQL temps de génération et de faire usage de la pré-compilés de la nature de la SP. Encore une fois, je ne dis pas de penser que c'est encore possible, ou qu'il y aurait à l'accélération. Il suffit de pointer une idée intéressante à sa question a engendré pour moi. Cette approche pourrait laisser toute la logique dans le code et de SP performances.
    • Je pense que vous avez mal compris la remarque que j'ai faite. Je parle de toutes les SP comme étant uniformément une mauvaise idée. Ce n'est pas "intéressant". C'est une erreur. La SP n'est pas comme par magie de créer haute performance.
    • Lott il n'est pas "magique". C'est plus rapide pour générer des "EXEC some_sp_name(avec, params)" que c'est de générer une grande instruction SQL. Vous pourriez dire, "eh bien, c'est juste les cordes, c'est super rapide". Ouais, mais si vous avez atteint un sommet dans l'ORM de django reinhardt, de génération SQL je pense que vous auriez du le voir, c'est un peu plus effrayant que ça. De Plus, des procédures stockées profiter de la SQL précompilés, comme une requête paramétrée. Je suis d'accord que les procédures stockées totalement sucer mais vous devez admettre que c'est une idée intéressante d'avoir l'ORM générer en toute transparence pour vous au lieu de générer le SQL à chaque fois.
    • Je parle de toutes les SP comme étant uniformément une mauvaise idée. De manière uniforme. Dans l'ensemble. Le code est présent dans deux endroits. Il ne semble jamais à travailler dans le long terme pour fragmenter le code tel qu'il est.
    • Ainsi, après 30 ans, on peut dire que de manière Uniforme et de l'Ensemble des procédures stockées sont une mauvaise idée? Wow qui couvre de nombreux cas, et je ne l'achetez pas pour une seconde. Il existe de nombreux cas là, et je ne peux pas imaginer que vous personnellement peut attester à tous. Seulement mes 2cents. Je peux venir avec beaucoup de cas qu'ils font de PARFAITS sens et d'autres cas où ils ne le font pas. Juste pour l'enregistrement dans certains cas, je peux imaginer ou ont travaillé sur je suis complètement d'accord avec vous et les autres, je suis de l'autre côté de l'univers à partir de votre point de vue.
    • vous êtes encore à l'incompréhension de ce que j'essayais de dire. Le code est toujours en UN seul endroit. Tout le code n'existe que dans les ORM logique en Python. Les procédures stockées dont je parle ne sont pas écrit par un programmeur. Lorsque l'ORM avis d'un certain exacte de la requête est envoyé beaucoup de choses, comme un micro-optimisation, l'ORM crée dynamiquement une nouvelle procédure stockée et utilisée à la place de générer du SQL à chaque fois. Pas de fragmentation de code! Les développeurs que écrire du code Python et tous les "avantages" de l'accord SPs sont acquis de manière transparente sans avoir à écrire de la SPs ou de "fragment" de votre logique métier.

    InformationsquelleAutor S.Lott
  6. 0

    Je suppose que l'amélioration de sql brut queryset soutien dans Django 1.2 pouvez rendre cela plus facile que vous ne l'auriez pas rouler vos propres make_instance type de code.

    InformationsquelleAutor Anentropic