Twisted + SQLAlchemy i najlepszy sposób na zrobienie tego

Question

Tak więc piszę kolejny demon oparty na Twisted. Będzie miał zwykły interfejs xmlrpc, dzięki czemu będę mógł łatwo komunikować się z nim, a inne procesy będą wymieniać z nim dane w razie potrzeby.

Ten demon musi mieć dostęp do bazy danych. Używamy SQL Alchemy zamiast twardych kodowania ciągów SQL dla naszych najnowszych projektów - najczęściej wykonywanych dla aplikacji internetowych w Pylonach.

Chcielibyśmy zrobić to samo dla tej aplikacji i ponownie użyć kodu biblioteki, który korzysta z SQL Alchemy. Więc co robić? No cóż, skoro ta biblioteka została napisana do użycia w aplikacji Pylons, to jest to prosty kod blokujący, do którego wszyscy są przyzwyczajeni, a wszystkie elementy nieblokujące są obsługiwane magicznie przez Pylony za pośrednictwem wątków, lokacji wątków i sesji na.

Teraz dla Twisted Myślę, że trochę utknąłem. Mógłbym:

1. Wystarczy napisać sql muszę bezpośrednio, czy to minimalne i korzystać z basenu dbapi w skręcona zrobić runInteractions etc kiedy trzeba uderzyć db.
2. Korzystaj z obiektów i z natury blokuj metody w naszej bibliotece, a następnie blokuj w moim demonie Twisted. Bah.
3. Użyj sAsync, który został ostatnio zaktualizowany w 2008 roku i ponownie używaj modeli, które już zdefiniowaliśmy, ale nie za bardzo, a to nie rozwiązuje problemu, że kod biblioteki musi działać również w Pylonach. Czy to działa nawet z najnowszą wersją SQL Alchemy? Kto wie. Ten projekt wyglądał świetnie - dlaczego został najwyraźniej porzucony?
4. Pomiń oddzielny podproces i pozwól mu poradzić sobie z kodem biblioteki i wszystkim, co blokuje, a wyniki są zwracane do mojego demona, gdy będą gotowe, gdy obiekty są przekierowywane przez YAML ponad xmlrpc.
5. Użyj funkcji deferToThread, a następnie zniszcz obiekty, które zostały zwrócone, upewniając się, że wykonujesz niecierpliwe ładunki, aby mieć wszystkie potrzebne rzeczy. Wydaje mi się, że to trochę ugha.

Jestem również zatrzymany przy użyciu Python 2.5.4 atm więc jeszcze nie 2.6 i nie sądzę, mogę po prostu zrobić import z przyszłości, aby uzyskać dostęp do nowego modułu wieloprocesorowe chłodnym rzeczy tam. Zgadza się, ale dość dobrze radzimy sobie z komunikacją międzyprocesową.

Tak więc pochylam się w kierunku opcji 4 głównie w taki sposób, aby uniknąć śmiertelnego grzechu powielania logiki z opcją 1, jednocześnie pozostając przy tym z dala od wątków.

Moja pierwsza próba będzie jednak opcją 2, aby po prostu uruchomić to, a następnie oddzielić połączenia do kodu bibliotecznego, być może, do osobnego procesu, jeśli wygląda na to, że istnieje spora szansa, że ​​coś może zająć trochę czasu blokować. Smutny. Może interesujące byłoby tu połączenie Stackless Python i Twisted.

Jakieś lepsze pomysły?

Answer 1

Po pierwsze, mogę niestety tylko zająć twoją opinię, że skręcone i SQLAlchemy nie grają bardzo dobrze. Pracowałem z niektórymi z nich zarówno i byłbym nieco boi się złożoności, która powstaje z łącząc je.

Wszystkie warstwy integracyjne bazy danych, które znam do tej pory, używają warstwy integracyjnej twisteds threading, a jeśli chcesz uniknąć tego przy kosztach , prawie utkniesz na punkcie 4 na liście.

Z drugiej strony widziałem przykłady bazy danych łączącej kod przy użyciu funkcji deferToThread() i znajomych, które działały bardzo dobrze.

Zresztą kilka wskazówek, jeśli byłbyś gotów rozważyć inne ramy niż SQLAlchemy:

Chłopaki divmod zostały jakiejś wstępną pracę na skręconej - integracji danych na podstawie Storm ORM (google " burza orm ").

Zobacz ten link przykład:

http://divmod.readthedocs.org/en/latest/products/nevow/storm-approach.html

również udać się na miejscu divmod i spojrzeć na źródłach ich warstwy Axiom db (prawdopodobnie nie stanowi jakiegokolwiek użytkowania do was bezpośrednio od to tylko Sqlite, ale zasady mogą być przydatne).

Answer 2

Istnieje gałąź burzy, z której można korzystać bezpośrednio po skręcie (wewnętrznie odkłada się na rzeczy gwintowane) na wyrzutni https://code.launchpad.net/~therve/storm/twisted-integration. Użyłem tego ładnie.

Niestety, sqlalchemy jest znacznie bardziej skomplikowana w implementacji do kontroli użycia asynchronicznego. Jeśli naprawdę chcesz go użyć, poleciłbym podejście poza procesem z warstwą rpc pamięci masowej.

alternatywnie, jeśli czujesz się na siłach i przy użyciu PostgreSQL, najnowsza pyscopg2 obsługuje prawdziwe wykorzystanie asynchronicznej (https://launchpad.net/txpostgres), a źródłem burza jest dość prosty hack na ;-)

nawiasem mówiąc burzy próbowałeś ubiegłym roku nie może mieć domyślnie włączone rozszerzenie C (jest ono teraz w najnowszych wersjach), które może wyjaśniać problemy z szybkością.

Answer 3

Być może ten twistar jest tym, czego szukasz. Jest to natywna, aktywna implementacja rekordu (zwana też ORM) dla skręcania, działająca na szczycie twisted.enterprise.adbapi.

http://findingscience.com/twistar/

Answer 4

W międzyczasie kilku lat, Alex Gaynor stworzony https://github.com/alex/alchimia które mogą być lepszym centralne repozytorium robi integrację z SQLAlchemy i zakręcony.