Utilizzando Python tipo di set di attuare ACL

Question

Attualmente ho tavoli come: Pages, Groups, GroupPage, Users, UserGroup. Con set salamoia posso realizzare la stessa cosa con solo 3 tavoli:. Pages, Groups, Users

set sembra una scelta naturale per l'attuazione ACL, come operazioni di gruppo e autorizzazioni legati possono essere espressi molto naturalmente con insiemi. Se devo conservare il acconsentire / rifiutare le liste come set in salamoia, può eliminare alcuni tavoli intermedi per molti-a-molti e consentire la modifica il permesso senza molte operazioni di database.

Se la leggibilità umana è importante, posso sempre usare JSON invece di cPickle per la serializzazione e utilizzare set durante la manipolazione della lista autorizzazione in Python. È altamente improbabile che le autorizzazioni saranno mai essere modificati direttamente utilizzando SQL. Quindi è una buona idea di design?

Stiamo usando SQLAlchemy come ORM, quindi è probabile che sia attuata con la colonna PickleType. Non ho intenzione di memorizzare l'intero set di record in salamoia "risorsa", solo l'oggetto set fatto di "risorsa" valori di chiave primaria.

Answer 1

Se avete intenzione di fare la serializzazione set, si dovrebbe trovare un buon database ad oggetti (come ZODB ). In un mondo puro-relazionale, il vostro set sono archiviati come BLOB, che funziona bene. Cercando di insiemi salamoia in una situazione ORM può portare a problemi confusi con i mapping ORM, in quanto essi presuppongono principalmente mappature puramente relazionali senza BLOB che devono essere decodificati.

Set e altri oggetti di prima classe sono davvero ciò che appartiene in un database. L'ORM è un hack, perché alcune persone pensano che i database relazionali sono "meglio", così abbiamo incidere in uno strato di mapping.

Vai con un database di oggetti e ci si accorge che le cose sono spesso molto più agevole.

---

Modifica

SQLAlchemy ha il proprio serializzatore.

http://www.sqlalchemy.org/docs/05 /reference/ext/serializer.html

Questa è né salamoia o cPickle. Tuttavia, perché ha bisogno di essere estensibile, si comporterà come salamoia. Che - per i vostri scopi - sarà veloce come è necessario. Non sarà deserializzazione di ACL per tutto il tempo.

Answer 2

È necessario considerare che cosa è che un DBMS fornisce, e quali di queste caratteristiche che dovrete reimplementare. La questione della concorrenza è un grande. Ci sono alcune condizioni di gara per essere considerati (ad esempio più scritture che si svolgono in diversi thread e processi e sovrascrivendo i nuovi dati), problemi di prestazioni (scrivere politica? Che cosa succede se si blocca il processo e si perde i dati?), Problemi di memoria ( quanto sono grandi i vostri set di autorizzazioni? Sarà tutti in forma in RAM?).

Se si dispone di memoria sufficiente e non devono preoccuparsi di concorrenza, allora la soluzione potrebbe essere un buon compromesso. In caso contrario, mi piacerebbe restare con un database -. Si prende cura di questi problemi per voi, e un sacco di lavoro è andato in loro per assicurarsi che essi hanno sempre prendere i dati da uno stato coerente ad un altro

Answer 3

Me, mi piacerebbe restare con mantenere persistente informazioni nel DB relazionale in una forma che è indipendente da un linguaggio di programmazione specifico utilizzato per accedervi - quanto io amo Python (e questa è una molto ), un giorno mi potrebbe voler accedere a queste informazioni da qualche altra lingua, e se sono andato per i formati Python-specifiche ... ragazzo avrebbe mai ne pentirete ...

Answer 4

Se si semplifica le cose e non sarà la modifica del file di un bel po '(o sarà modificato di rado), dico andare per esso. Naturalmente, una terza opzione da considerare è utilizzando un href="http://docs.python.org/library/sqlite3.html" rel="nofollow noreferrer"> banca dati