Quali sono alcune buone soluzioni Python ORM? [chiuso]


210

Sto valutando e sto cercando di utilizzare CherryPy per un progetto che è fondamentalmente un front-end JavaScript dal lato client (browser) che parla con un servizio web Python sul back-end. Quindi, ho davvero bisogno di qualcosa di veloce e leggero sul back-end che posso implementare usando Python che poi parli al DB PostgreSQL tramite un ORM (JSON al browser).

Sto anche guardando Django, che mi piace, dal momento che il suo ORM è incorporato. Tuttavia, penso che Django potrebbe essere un po 'più di quello di cui ho veramente bisogno (cioè più funzioni di quante ne abbia davvero bisogno == più lento?).

Qualcuno ha esperienza con diverse soluzioni Python ORM in grado di confrontare e confrontare le loro caratteristiche e funzionalità, velocità, efficienza, ecc.?


ponyORM sembra piuttosto carino.
Niklas R,

La mappatura relazionale a oggetti (ORM) è già molto popolare in molti linguaggi di programmazione e una delle migliori alternative per SQL. Mi sono ispirato allo stile del concatenamento di metodi per creare CQL per il mio progetto TRIADB. healis.eu/triadb/#latest-release
Athanassios

Risposte:


96

SQLAlchemy è più completo e potente (utilizza il modello DataMapper). Django ORM ha una sintassi più pulita ed è più facile scrivere per (modello ActiveRecord). Non conosco le differenze di prestazioni.

SQLAlchemy ha anche un livello dichiarativo che nasconde una certa complessità e gli conferisce una sintassi in stile ActiveRecord più simile all'ORM di Django.

Non mi preoccuperei che Django sia "troppo pesante". È abbastanza disaccoppiato che puoi usare l'ORM se vuoi senza dover importare il resto .

Detto questo, se avessi già utilizzato CherryPy per il livello Web e avessi solo bisogno di un ORM, probabilmente avrei optato per SQLAlchemy.


7
Ma se non ti piace l'ORM di Django e vuoi usare SA, ad esempio, perdi molte funzionalità di django, come admin. Non un rompiscatole, ma un ginocchio dalla pelle.
Gregg Lind,

22
Vero, ma irrilevante per la domanda, che riguardava semplicemente la scelta di un ORM Python; non sulle interfacce di amministrazione generate automaticamente o su altri componenti del framework.
Carl Meyer,

8
Direi che SQLAlchemy è tutt'altro che leggero, ma può essere abbastanza veloce. Getterò il mio progetto nel mix, si chiama peewee e parla con Postgres. Di recente ha aggiunto anche il supporto per le query in stile django! charlesleifer.com/docs/peewee
coleifer

3
Si noti inoltre che Django ORM non supporta le chiavi primarie composite e SQLAlchemy lo supporta.
Marcin Kapusta,

1
@yegle Sono confuso dal tuo commento. Non capisco la logica. In che modo "difficile trovare istruzioni ORDER BY DESCnei documenti" implica "non valido per il modello di record attivo"?
jpmc26,

108

Se cerchi un modello leggero e conosci già i modelli dichiarativi in ​​stile django, dai un'occhiata a peewee: https://github.com/coleifer/peewee

Esempio:

import datetime
from peewee import *

class Blog(Model):
    name = CharField()

class Entry(Model):
    blog = ForeignKeyField(Blog)
    title = CharField()
    body = TextField()
    pub_date = DateTimeField(default=datetime.datetime.now)

# query it like django
Entry.filter(blog__name='Some great blog')

# or programmatically for finer-grained control
Entry.select().join(Blog).where(Blog.name == 'Some awesome blog')

Controlla i documenti per altri esempi.


mi potete aiutare per questa domanda? Pls ru.stackoverflow.com/q/1114189/293323
Cookie

81

Storm ha probabilmente l'API più semplice:

from storm.locals import *

class Foo:
    __storm_table__ = 'foos'
    id = Int(primary=True)


class Thing:
    __storm_table__ = 'things'
    id = Int(primary=True)
    name = Unicode()
    description = Unicode()
    foo_id = Int()
    foo = Reference(foo_id, Foo.id)

db = create_database('sqlite:')
store = Store(db)

foo = Foo()
store.add(foo)
thing = Thing()
thing.foo = foo
store.add(thing)
store.commit()

E rende indolore cadere in SQL raw quando è necessario:

store.execute('UPDATE bars SET bar_name=? WHERE bar_id like ?', []) 
store.commit()

Va notato che Storm supporta solo MySQL e PostgreSQL al momento attuale. Il supporto Oracle è in lavorazione però.
Jason Baker,

15
Supporta anche SQLite come suggerisce l'esempio sopra
shearichard

2
quick_orm è semplice come Storm ed è basato su SQLAlchemy, quindi è anche molto potente: pypi.python.org/pypi/quick_orm . Disclaimer: sono l'autore di quick_orm
Tyler Long,

8
Storm non è mantenuto. Non lo userei per nuovi progetti.
Matthias Urlichs,

3
Inoltre, sembra che non ci sia Storm for Python 3
ygormutti il

27

Di solito uso SQLAlchemy . È piuttosto potente ed è probabilmente il più maturo ORM in pitone.

Se stai pensando di utilizzare CherryPy, potresti anche esaminare dejavu in quanto è di Robert Brewer (il ragazzo che è l'attuale capo del progetto CherryPy). Personalmente non l'ho usato, ma conosco alcune persone che lo adorano.

SQLObject è un po 'più semplice da utilizzare ORM rispetto a SQLAlchemy, ma non è altrettanto potente.

Personalmente, non userei Django ORM se non avessi intenzione di scrivere l'intero progetto in Django, ma sono solo io.


SQLObject è eccezionale - semplice da usare, indipendente dal database e può davvero fare le tabelle per te! (Sono pigro).
Lucas Jones,

1
@Lucas - Anche SQLAlchemy ...
Jason Baker,

Per quanto posso ricordare, stavo solo complimentando con SQLObject. È stato tanto tempo fa, però ... :)
Lucas Jones,

@Lucas - L'ho pensato come tale. Ho solo pensato di prenderne nota. :-)
Jason Baker,

17

L' estensione dichiarativa di SQLAlchemy , che sta diventando standard in 0.5, fornisce un'interfaccia tutto in uno molto simile a quella di Django o Storm. Si integra perfettamente anche con le classi / tabelle configurate utilizzando lo stile datamapper:

Base = declarative_base()

class Foo(Base):
    __tablename__ = 'foos'
    id = Column(Integer, primary_key=True)

class Thing(Base):
    __tablename__ = 'things'

    id = Column(Integer, primary_key=True)
    name = Column(Unicode)
    description = Column(Unicode)
    foo_id = Column(Integer, ForeignKey('foos.id'))
    foo = relation(Foo)

engine = create_engine('sqlite://')

Base.metadata.create_all(engine)  # issues DDL to create tables

session = sessionmaker(bind=engine)()

foo = Foo()
session.add(foo)
thing = Thing(name='thing1', description='some thing')
thing.foo = foo  # also adds Thing to session
session.commit()

Ma le cose diventano molto complesse se ci sono molte relazioni come one_to_many, many_to_many, ereditarietà della tabella. Devi scrivere molto codice a mano per gestirli. Controlla la mia risposta per Quick ORM. Può farti risparmiare tempo.
Tyler Long,

18
:) a Tyler che dice al creatore di SQLAlchemy che dovrebbe usare Quick ORM.
Anthony Briggs,

5
:) Mi ricorda qualcuno anni fa su usenet che discuteva con dmr @ alice che non capiva davvero C.
Peter Rowell,

@AnthonyBriggs, controlla questa diapositiva e vedrai perché quick_orm è migliore nella gestione di relazioni complesse rispetto a SQLAlchemy: slideshare.net/tyler4long/quickorm
Tyler Long

10

Usiamo Elisir insieme a SQLAlchemy e finora ci è piaciuto. Elisir mette uno strato sopra SQLAlchemy che lo fa sembrare più simile alle controparti "Pattern ActiveRecord".


2
SQLAlchemy supporta OOP e stili funzionali pronti all'uso, Elixir aggiunge uno stile di programmazione dichiarativo (principalmente per le dichiarazioni dei modelli, ma può essere esteso).
Muhuk,

5

Questo sembra essere il punto di riferimento canonico per l'interazione di database di alto livello in Python: http://wiki.python.org/moin/HigherLevelDatabaseProgramming

Da lì, sembra che Dejavu implementa il pattern DataMapper di Martin Fowler in modo abbastanza astratto in Python.


Ero interessato e guardavo Dejavu. Solo un po. La documentazione è molto scarsa (qoute "per il livello di presentazione che sei da solo") quindi direi solo agli utenti esperti.
r4.

1

Penso che potresti guardare:

Autunno

Tempesta


L'autunno è probabilmente più facile di Storm, ma Storm include molte funzionalità che Autumn non ha. Entrambe queste opzioni hanno una documentazione limitata, anche se Storm sta risolvendo così velocemente!
alecwh,

Grazie, Autumn sembra molto bello e attraente, ma non ha documentazione, il che è un grosso problema per me.
temoto

1
Ho appena provato alcuni degli esempi nella pagina autunnale e non funzionano nemmeno con la versione del codice installata dal mio gestore pacchetti. Anche i post nel gruppo google sono vecchi. Sembra che il progetto stia morendo lentamente. Non consiglierei di usarlo.
Jason Miesionczek,

Storm d'altra parte, sta rapidamente diventando il mio ORM preferito. I documenti stanno migliorando e l'API è chiara e semplice, sebbene io sia un po 'più abituato al modello ActiveRecord utilizzato dall'ORM di Django, trovo Storm facile da navigare.
Jason Miesionczek,

1
Autum non sembra avere attività per un anno. groups.google.com/group/autumn-orm
Sridhar Ratnakumar,

1

Non è plausibile che le funzionalità inutilizzate di Django penalizzino le prestazioni. Potrebbe tornare utile se decidi di migliorare il progetto.


8
c'è un concievable modo
bukzor

0

Ho usato Storm + SQLite per un piccolo progetto e ne sono rimasto abbastanza soddisfatto fino a quando non ho aggiunto il multiprocessing. Il tentativo di utilizzare il database da più processi ha comportato un'eccezione "Il database è bloccato". Sono passato a SQLAlchemy e lo stesso codice ha funzionato senza problemi.


7
Ad essere onesti, SQLite non è progettato per accessi simultanei.
Xiong Chiamiov

2
@Xion +1. SQLITE è un solo file, senza daemon in esecuzione.
e-satis

-1

SQLAlchemy è molto, molto potente. Tuttavia, non è sicuro per i thread, assicurati di tenerlo presente quando lavori con cherrypy in modalità pool di thread.


2
è vero che SQLAlchemy non è thread-safe? Quindi come viene utilizzato nelle app Pyramid su WSGI, che principalmente le persone distribuiscono in modalità threaded? Qualsiasi conferma a questa affermazione contraddittoria.
Ravi Kumar,

1
Ovviamente SQLAlchemy è thread-safe.
Matthias Urlichs,

-7

Darei un'occhiata a SQLAlchemy

È davvero facile da usare e i modelli con cui lavori non sono affatto male. Django utilizza SQLAlchemy per il suo ORM ma usarlo da solo ti consente di sfruttare tutta la sua potenza.

Ecco un piccolo esempio sulla creazione e selezione di oggetti orm

>>> ed_user = User('ed', 'Ed Jones', 'edspassword')
>>> session.add(ed_user)
>>> our_user = session.query(User).filter_by(name='ed').first() 
>>> our_user
    <User('ed','Ed Jones', 'edspassword')>

18
Django non usa sqlalchemy per il suo ORM. C'è stato del lavoro fatto per rendere sqlalchemy un ORM opzionale, ma non è completo.
Sherbang,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.