Comment 8 for bug 307718

Hey very good, O(1) for me! So with your caching it sounds like reading all the selected records is perfectly OK!
Ah, ah I chatted with the Tryton guys, Krier was saying your cache was not a good solution... Well one more proof it is!

Okay, I don't know about any other object suffering that kind of trouble, but if we find some we will let you know.

Saw your quality module. Last time I check some one week ago, I had very non consistent/absurd result like overall -3/10 for the built'in sale module, same kind of numbers for my own modules... So I hopped it's properly calibrated by now.

Oh, by the way: I think the first criteria of quality should be: if you find a module with less than 5 lines in its terp meta description, please just rate it 0, this should force people to document their stuff in a Googlable fashion.

Oh, by the way, about documentation and your cache system: both Pedro Tarafeta and I couldn't find out how your cache in sale order really does:
            store={
                'sale.order': (lambda self, cr, uid, ids, c={}: ids, None, 10),
                'sale.order.line': (_get_order, None, 10),
            },

What does that mean, what 10 means? I have a case where I should also trigger a cache invalidation, please could you document that in your dev wiki? Is 10 some kind of constant key? If yes, in Java we usually name constant key with an UPPER_CASE_STRING as an explicit indirection, nothing similar in Python?

Thank your, keep it up with the great work!