cómo crear un modelo Django que no se correlaciona con una tabla de base de datos

Question

Quiero crear un modelo que no se asocie a una tabla de base de datos. En cambio, se queda en la memoria como un objeto python.

En realidad, se supone que este modelo representa datos normalizados de muchos otros modelos de tabla asignada.

Los otros modelos almacenan datos que se pueden editar varias veces en un solo día. Debido a estas ediciones múltiples, no quiero un modelo mapeado en tabla que realice normalizaciones/cálculos y los almacene en una base de datos, ya que estos datos almacenados pueden quedar desactualizados de inmediato.

Cada vez que se accede a este modelo normalizado (a través de admin), quiero realizar las normalizaciones de los datos desde los otros modelos desde cero (para que pueda mostrar los datos más actualizados) y comportarme como un normal modelo bajo administración como Mostrar la vista de lista y una vista detallada para cada fila.

Edición después de la respuesta de Shintoist:

Gracias @Shintoist de las cosas y la limpieza de proporcionar un enfoque útil. Acabo de implementarlo, pero al final toco un pequeño muro :)

@skirmantas: Sí, los cálculos están en un objeto separado. Este objeto se está pasando a las vistas personalizadas.

Problema: Un problema es que bajo admin.py, he creado un modeladminclass para este objeto (que no hereda models.Model) por lo que mis vistas personalizadas pueden sobreponerse a la vista de lista de cambios y a la vista de cambio. Luego uso admin.site.register() para registrar esta clase de modelo y modeladmin. Pero, dado que este modelo no es en absoluto un modelo de django (ya que es un objeto python independiente en la memoria) admin.site.register() arroja un error de "tipo" el objeto no es iterable ". No quiero usar el url.py en lugar de admin.py, ya que está destinado a la interfaz mientras trato de superar al administrador de backend.

Answer 1

hmmm. Gracias por su ayuda a todos.La solución que he llegado (con su ayuda por supuesto) es la siguiente:

que tienen dos plantillas personalizadas:

my_model_list.html 
    my_model_detail.html 

Bajo 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) 

Bajo las principales direcciones URL django .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)) 
) 

Como ya se ha notado, he tenido que insertar patrones de URL a mi archivo url.py. No sé si esa es la mejor manera de hacerlo, ya que considero que el archivo url.py no es para páginas relacionadas con el administrador. Es solo para la interfaz del sitio.

Answer 2

¿Por qué tener un modelo en absoluto? Haga referencia a sus cálculos en una vista, escriba una plantilla y requiera el inicio de sesión de administrador para acceder a ella. Eso recrearía estos datos normalizados solo cuando cargue la página y solo existiría en la memoria, lo que le ahorraría recursos.

Answer 3

¿Qué ocurre con el uso de múltiples bases de datos y la configuración de una de ellas para usar tablas en memoria?

Para MySQL se vería así:

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

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

Tenga en cuenta que sólo tendrá que utilizar SET storage_engine al crear tablas, pero podría ser que no se le añade demasiada sobrecarga de todos modos para su caso de uso.

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

Answer 4

Dependiendo de la complejidad de estos "cálculos" son, parece que desea una costumbre database view (apoyado, creo, por SQLite, MySQL, PostgreSQL y Oracle, al menos) que se utiliza en conjunción con un modelo con Meta.managed=False.

Si tiene suerte, podrá obtener South para crearlo para usted en una migración, pero aún no parece que South admita vistas.