smartleaders and all: interesting, but:
1) are you absolutely sure your speed problem comes from the transfer size? and the form definition? The GTK already have a cache system but may be it could be improved to avoid re-transfering the same form definition over and over as it seems the case (field_view_get method or something like that if I remember correctly). I say this because opening a product from form the product list view for instance has already been very slow for other reasons than the form definition transfer, see point 3). 2) You should definitely try v5. RC3 has just been tagged in the trunk, we have customers getting it in prod in a matter of a week and it's A LOT faster. Mainly they worked out smart ORM cache systems and database transactional cache for python computed fields, but there are a lot of improvement in general. 3) As for the data size with the GTK client, I think you could do a simple change inside the GTK clients. Indeed, currently, Tiny made a different decision for the GTK client than the eTiny client: with the GTK client, if you open some entity in list view and then request a form view of some selected entity from the list, the extra form data fields will (computed or data base based) will be request FOR ALL the listed entities. What motivated their decision is that their cache system allows them to request ne entities in O(1), not O(n). So it's like a single database request and then swictching from entities using forward en back button is almost instantaneous. The trouble still is that: * yes is does make the first data to transfer a lot larger when you request an entity in form view (unlike eTiny). * If for whatever reason (and might probably often be the case in v4.2), like a not so clean module, then your access time can rise form O(1) to O(n). For instance, there was a bug in v5, some 2 weeks ago, where accessing a product form from the list view was 6 seconds (first access) instead of less than one second on our system!!!! This has be corrected in trunk, but there could be offender modules and as I say I don't know where v4.2 stands here. Also they build a module called 'base_module_quality' (v5; work in progress), which, among other things, test access time is o(1). This also make modules a bit harder to design for the average coder that's why I think this would have been nice to let the choice at configuration if you want this behavior or eTiny way of loading data. A work around in case of O(n) access time (and a good way to test it) is to decrease the number of record to display in list view. For instance, with the product list/form view, we could pass form 6 second access time with 80 records to 3 seconds displaying only 40 records (action window setup). But as I said this has been fixed. Finally you probably should read those two things: https://bugs.launchpad.net/bugs/307718 https://blueprints.launchpad.net/openobject-client/+spec/disconnected-mode Please provide feedback on this. We all are very interested in performance feedback. Raphaël Valyi ------------------------ http://www.smile.fr -------------------- m2f -------------------- -- http://www.openerp.com/forum/viewtopic.php?p=28133#28133 -------------------- m2f --------------------
_______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman/listinfo/tinyerp-users
