Hello folks a few remarks. I tend to agree with Albert but I'm not 100% sure. Here is why:
- I agree 99% of the time we have the context so no perf overhead 99% of the time
- xrg: "why don't we simply fix the 1% remaining where context is not passed right?" Because this would probably imply changing the method API sometimes and this is not allowed (or should not be allowed) during the life of ""stable"" releases. Or may be I'm wrong and this is just about adding the context argument in method calls, but I doubt this is that benign.
So yes in the long-run let's fix it; but in the short run, Albert solution might be a good workaround.
I would add:
- xrg: when you don't want to translate: wouldn't that be possible to explicitly pass "en_US" in the context rather than nothing? Then no perf impact with uid.
- what do you think about that: Actually it's likely a user doesn't spent his time switching languages. So why not store a key 'uid':lang in some osv_memory object and if present we use it instead of hitting the database with the uid. If the user change it's language during his session, well, in 1% of cases he could have a wrong language, that's already much better than today. We could even drop the osv_memory key when this happen.
I know all this looks ugly. But IMHO this is "real politic", now 6.0 is supposed to be stable and changing methods API is no solution, we should do whatever is acceptable (and flagged properly as being a workaround) during those 6 months to fix usability. And yes, may be next time we should think twice about API stability in first place before freezing a release.
Hello folks a few remarks. I tend to agree with Albert but I'm not 100% sure. Here is why:
- I agree 99% of the time we have the context so no perf overhead 99% of the time
- xrg: "why don't we simply fix the 1% remaining where context is not passed right?" Because this would probably imply changing the method API sometimes and this is not allowed (or should not be allowed) during the life of ""stable"" releases. Or may be I'm wrong and this is just about adding the context argument in method calls, but I doubt this is that benign.
So yes in the long-run let's fix it; but in the short run, Albert solution might be a good workaround.
I would add:
- xrg: when you don't want to translate: wouldn't that be possible to explicitly pass "en_US" in the context rather than nothing? Then no perf impact with uid.
- what do you think about that: Actually it's likely a user doesn't spent his time switching languages. So why not store a key 'uid':lang in some osv_memory object and if present we use it instead of hitting the database with the uid. If the user change it's language during his session, well, in 1% of cases he could have a wrong language, that's already much better than today. We could even drop the osv_memory key when this happen.
I know all this looks ugly. But IMHO this is "real politic", now 6.0 is supposed to be stable and changing methods API is no solution, we should do whatever is acceptable (and flagged properly as being a workaround) during those 6 months to fix usability. And yes, may be next time we should think twice about API stability in first place before freezing a release.