2012-01-26 7 views
8

Questa è una domanda strana, lo so, ma sopporta me. Abbiamo sviluppato una piattaforma RESTful usando Python per una delle nostre app per iPhone. La versione webapp è stata creata utilizzando Django, che utilizza anche questa API. Pensavamo che sarebbe stata una grande idea utilizzare le funzionalità integrate del pannello di controllo di Django per aiutare a gestire i dati.Django Admin che utilizza API RESTful v.s. Database

Questo non è il problema. Il problema è che tutti hanno deciso che sarebbe meglio che l'admin center fosse essenzialmente un client che si trova sulla piattaforma RESTful.

Quindi, la mia domanda è: c'è un modo per manipolare il livello del modello di Django per accedere direttamente alla nostra API, piuttosto che comunicare direttamente con il database? Il livello del modello agirà come client che trasmette le richieste e le risposte da e verso l'admin center.

Sono sicuro che sia possibile, ma non sono sicuro di dove iniziare. Qualche input?

+1

niente è impossibile, ma sembra molto lavoro. Se riesci a connettere django al DB, ti risparmierai un sacco di tempo. Posso capire il desiderio di usarlo come app di prova per l'API, ma forse c'è un'app diversa che potresti creare, o persino scrivere casi di test. – monkut

+1

Sembra più lavoro di quanto varrebbe la pena. Probabilmente dovresti esaminare i Model Manager o un back-end db personalizzato. – jdi

+0

Wilhelm, sto affrontando la stessa situazione. L'hai mai risolto come volevi o ti sei arreso e accedi direttamente al database? – JoaoPSF

risposta

0

Mi ricordo che una volta ho pensato di fare una cosa del genere. Al momento, ho creato un gestore personalizzato utilizzando un query set personalizzato. E ho annullato alcuni metodi come _filter_or_exclude(), count(), exists(), select_related(), ... e aggiunto alcune proprietà. Ci è voluta meno di una settimana per diventare un disastro totale che probabilmente non aveva alcuna possibilità di lavorare un giorno. Così ho immediatamente fermato tutto e trovato una soluzione più adatta.

Se dovessi farlo ancora una volta, impiegherei molto tempo a considerare le alternative. E se davvero sembra la cosa migliore da fare, probabilmente creerei un back-end database personalizzato. Questo backend, invece di convertire le query ORG di Django in query SQL, convertirle in richieste HTTP.

Per fare ciò, ritengo che il miglior punto di partenza sia acquisire familiarità con django source code concerning database backends.

Penso anche che ci sono alcune cose importanti da considerare prima di iniziare tale sviluppo:

  • è l'API in grado di gestire qualsiasi richiesta Django ORM? Detto in altro modo: una qualsiasi query di Django ORM può essere tradotta in una richiesta API?
  • In caso contrario, le query "non traducibili" possono essere ignorate in modo sicuro? Ad esempio, una clausola ORDER BYpotrebbe essere ignorata in modo sicuro. Mentre è molto improbabile che una clausola GROUP BY venga archiviata in modo sicuro.
  • Se alcune query non possono essere né tradotte né ignorate, potrebbero essere ragionevolmente emulato. Ad esempio, se la tua API non supporta l'operazione COUNT(), potresti emularla recuperando tutti i dati e contarli in python con len(), ma è ragionevole?
  • Se sono ancora alcune query che non sarete in grado di gestire (che è più che probabile): tutte le query "comuni" (in questo caso, tutte le query potenzialmente utilizzate da Django Admin) sono coperte e sarà è possibile aggiornare l'API se un caso scoperto viene scoperto di recente o introdotto in una versione futura di Django?

Secondo il caso d'uso, ci sono probabilmente un sacco di altre considerazioni da prendere, come ad esempio:

  • l'integrità dei dati
  • supporto delle transazioni
  • i tempi di una query che sarà probabilmente molto più alto di una query su un database locale (o anche remoto).