ARGOMENTO: Limitazioni "fisiche" di OpenERP

Mi trovo ora a scrivere un'applicazione di OpenERP che deve essere in grado di memorizzare e gestire circa 300 ordini di vendita al giorno importati automaticamente.

Qualcuno ha avuto esperienza di gestione di una mole di dati paragonabile? Come si comporta l'applicativo? è in grado di supportarla?
Sapere se esiste nella documentazione tecnica di Tiny qualche documento che indichi i limiti "fisici" dell'ERP?

Noi siamo a decine di migliaia di aggiornamenti ogni 4 ore circa.

Più che limiti di OpenERP, dovresti documentarti sui limiti di Postgresql, che dipendendo più che altro dalle caratteristiche del sistema operativo e dell'hardware, siccome ha di per se un'architettura molto robusta.

dimenticavo...
dipende poi molto da che tecnica utilizzi per fare gli import automatici.
Il modulo ETL è nato apposta per questo, ma è anche un po' ostico.

Script custom che importano via XML-RPC sono invece i più semplici da implementare.
Se devi fare controlli particolari, ovviamente il tutto si appesantisce un po' e l'orm di openobject può avere colli di bottiglia, ma su un server di fascia medio/bassa (Xeon quadricore, 8gb di ram nei nostri test) proprio nell'import di ordini, arrivi comunque a decine di migliaia di record all'ora se non abbondi con i controlli via xml-rpc nei tuoi script.

Ieri ho mandato in esecuzione un piccolo test di importazione XML-RPC di 20.000 ordini di vendita con XML-RPC, con tanto di verifiche e ricerche di record collegati prima dell'inserimento di ciascun ordine e avvio automatico del workflow all'inserimento. E' andato tutto liscio, importazione abbastanza veloce, nessun grave problema di latenza nella successiva consultazione dei record importati.

Certo... non sarebbe male un meccanismo di cache "read forward" quando si consultano gli elenchi di oggetti. Magari Tiny ci penserà per le prossime edizioni, non è così importante.

In ogni caso, da una velocissima ricerca sul web, ecco le limitazioni di Postgres:
archives.postgresql.org/pgsql-admin/2001-01/msg00192.php

in realtà la base per costruirsi della cache esiste già.
Diciamo che la natura dei dati su cui si lavora generalmente con openerp/openobject non richiede cache siccome si tratta di dati altamente variabili in molti casi (disponibilità) e altri (dati partner) molto circoscritti.

cmq osv.memory dovresti poter "giocare" un po', anche se non è proprio nato per gestire cache su viste, ma più che altro per simulare la gestione di una session