come creare un modelli di Django che non mappano ad una tabella di database

Question

Voglio creare un modello che non la mappa a una tabella di database. Invece, rimane in memoria come oggetto python.

In realtà, questo modello si suppone che rappresenta i dati normalizzati di molti altri modelli di tabella mappata.

L'altra dati modelli negozio che può essere modificato più volte in un solo giorno. A causa di queste modifiche multiple, non voglio che un modello mappato alla tabella esegua normalizzazioni/calcoli e li memorizzi in un database poiché, questi dati memorizzati possono non essere aggiornati immediatamente.

Ogni volta che si accede a questo modello normalizzato (tramite admin), voglio che esegua la normalizzazione dei dati dagli altri modelli da zero (in modo che possa mostrare i dati più aggiornati) e si comporti come un normale il modello sarebbe sotto admin come Mostra la vista elenco e una vista dettagliata per ogni riga.

Modifica dopo la risposta di shintoista:

Grazie @Shintoist per la compensazione le cose e che forniscono un approccio utilizzabile. Ho appena implementato, ma colpire un muretto alla fine :)

@skirmantas: Sì, i calcoli sono in un oggetto separato. Questo oggetto viene passato nelle visualizzazioni personalizzate.

Problema: Un problema è che sotto admin.py, ho creato un modeladminclass per questo oggetto (che non eredita models.Model) così le mie visualizzazioni personalizzate può overide la vista elenco modifiche e ChangeView. Quindi uso admin.site.register() per registrare questa classe simile al modello e il modeladmin. Ma poiché questo modello non è affatto un modello di django (dato che è un oggetto python indipendente in memoria) admin.site.register() lancia un errore di tipo "tipo" non è iterabile ". Non voglio usare url.py invece di admin.py perché è pensato per il frontend mentre sto cercando di sovrascrivere l'amministratore di backend.

Answer 1

hmmm. Grazie per il tuo aiuto a tutti.La soluzione che ho messo a punto (con il vostro aiuto naturalmente) è la seguente:

ho due modelli personalizzati:

my_model_list.html 
    my_model_detail.html 

Under views.py:

class MyModel(object): 
    # ... Access other models 
    # ... process/normalise data 
    # ... store data 

@staff_member_required 
def my_model_list_view(request) #show list of all objects 
    #. . . create objects of MyModel . . . 
    #. . . call their processing methods . . . 
    #. . . store in context variable . . . 
    r = render_to_response('admin/myapp/my_model_list.html', context, RequestContext(request)) 
    return HttpResponse(r) 

@staff_member_required 
def my_model_detail_view(request, row_id) # Shows one row (all values in the object) in detail  
    #. . . create object of MyModel . . . 
    #. . . call it's methods . . . 
    #. . . store in context variable . . . 
    r = render_to_response('admin/myapp/my_model_detail.html', context, RequestContext(request)) 
    return HttpResponse(r) 

Sotto il Django principali degli URL .py:

urlpatterns = patterns( 
    '', 
    (r'^admin/myapp/mymodel/$', my_model_list_view), 
    (r'^admin/myapp/mymodel/(\d+)/$', my_model_detail_view), 
    (r'^admin/', include(admin.site.urls)) 
) 

Come avete già notato, ho dovuto inserire modelli di URL al mio file url.py. Non so se questo sia il modo migliore per farlo, come penso, il file url.py non è pensato per le pagine relative all'amministrazione. È solo per il frontend del sito.

Answer 2

Perché avere un modello? Fai riferimento ai tuoi calcoli in una vista, scrivi un modello per esso e richiede l'accesso come amministratore per accedervi. Questo ricreverebbe i dati normalizzati solo quando caricate la pagina e verrebbero sempre presenti solo in memoria, risparmiando risorse.

Answer 3

Cosa succede ad usare più database, e la configurazione di uno di loro di utilizzare tabelle in memoria?

Per MySQL sarebbe simile a questa:

DATABASES = { 
    'default': { 
    }, 
    'memory': { 
     'ENGINE': 'django.db.backends.mysql', 
     'NAME': 'dbname', 
     'USER': 'dbuser', 
     'PASSWORD': '', 
     'HOST': 'localhost', 
     'PORT': '',   

     'OPTIONS': {"init_command": "SET storage_engine=MEMORY"} 
    } 
} 

Nota che avete solo bisogno di usare SET storage_engine durante la creazione di tabelle, ma potrebbe essere che non aggiunge troppo in alto in ogni caso per il vostro caso d'uso.

http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html

Answer 4

seconda della complessità questi "calcoli" sono, suona come si desidera un costume database view (sostenuto, credo, da SQLite, MySQL, Postgres, e Oracle, almeno) utilizzato in combinazione con un modello con Meta.managed=False.

Se siete fortunati, sarete in grado di ottenere del Sud per creare per voi in una migrazione, ma non assomiglia Sud supporta ancora viste.