Archives
Contributors
Concurrency write check
by Sergio Corato - 06:26 - 14 Feb 2024
Follow-Ups
-
Re: Concurrency write check
> I guess it's easy to (re)build this as an OCA module, although instances that install it will probably also run into the problems that made Odoo ditch it.
I agree, a less impacting solution should be better.
Il giorno ven 16 feb 2024 alle ore 15:12 David Vidal <notifications@odoo-community.org> ha scritto:> From my pov, a simple advice, on the UI with a js, should be enough to point out the fact.In the web_editor there's a kind of concurrence protection: https://github.com/OCA/OCB/blob/15.0/addons/web_editor/controllers/main.py#L32-L39Interesting, but it's only implemented for collaborative pages on web (events? I couldn't find where).Sergio CoratoEl vie, 16 feb 2024 a las 14:32, Sergio Corato (<notifications@odoo-community.org>) escribió:From my pov, a simple advice, on the UI with a js, should be enough to point out the fact.Sergio CoratoIl giorno ven 16 feb 2024 alle ore 10:32 Ronald Portier <notifications@odoo-community.org> ha scritto:So basically Odoo has no longer any mechanism to prevent the changes of one user undoing the changes of another user.
In applications traditionally two mechanisms existed that intended to prevent this problem, respectively pessimistic and optimistic locking.
In pessimistic locking anybody touching a record with the potential to update it, would establish a lock on the record, other users would be prevented from reading the same record for update. This has the potential for lots of access problems, especially as databases and transactions became more complicated and would no longer involve single records but whole networks of records.
Optimistic locking would, as Odoo does, timestamp all records. The idea that most reads that have a potential to update a record, mostly would not be updating anything. But when updating, the timestamp of the record read would be compared with the current timestamp and any previous change would result in an Exception.
An alternative method for optimistic locking, not depending on timestamps, would be to save the original record image and compare with the actual record image just before the actual update.
Missing either pessimistic locking or optimistic locking, for some applications it might be needed to implement a mechanism where a user must specifically claim a main application object for change, before being allowed to update it. A claim made preventing other users from making the same claim, before the application object being released. A main application object could be a Customer, an Order or a Helpdesk Ticket. Such a claim would work like a "check out" in document management systems, or a kind of Semaphore on OS level.
On 15-02-2024 23:11, Tom Blauwendraat wrote:
Closest I could come in finding some info about it is this:
https://github.com/odoo/odoo/pull/87756
Apparently it caused problems and was already long ago removed from the frontend, and by 16.0 they killed the backend part as well.
On 2/15/24 19:07, Sergio Corato wrote:
The logic isn't implemented/enabled in any version that I checked, this seems at least strange (I saw this function working in other softwares decades ago).Debugging didn't help, the context is never passed with the field '__last_update'.
However it's not a requested function, I'll give up for now ;)
Thanks
Sergio Corato
Il giorno gio 15 feb 2024 alle ore 17:07 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:
I also looked for unit tests and didn't find, and also saw this function was deleted in 16.0 (but maybe renamed). I think debugging is the only way to find out! pdb to the rescue
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Sergio Corato - 04:11 - 16 Feb 2024 -
Re: Concurrency write check
I guess it's easy to (re)build this as an OCA module, although instances that install it will probably also run into the problems that made Odoo ditch it.
On 2/16/24 14:32, Sergio Corato wrote:
From my pov, a simple advice, on the UI with a js, should be enough to point out the fact.
Sergio Corato
Il giorno ven 16 feb 2024 alle ore 10:32 Ronald Portier <notifications@odoo-community.org> ha scritto:
So basically Odoo has no longer any mechanism to prevent the changes of one user undoing the changes of another user.
In applications traditionally two mechanisms existed that intended to prevent this problem, respectively pessimistic and optimistic locking.
In pessimistic locking anybody touching a record with the potential to update it, would establish a lock on the record, other users would be prevented from reading the same record for update. This has the potential for lots of access problems, especially as databases and transactions became more complicated and would no longer involve single records but whole networks of records.
Optimistic locking would, as Odoo does, timestamp all records. The idea that most reads that have a potential to update a record, mostly would not be updating anything. But when updating, the timestamp of the record read would be compared with the current timestamp and any previous change would result in an Exception.
An alternative method for optimistic locking, not depending on timestamps, would be to save the original record image and compare with the actual record image just before the actual update.
Missing either pessimistic locking or optimistic locking, for some applications it might be needed to implement a mechanism where a user must specifically claim a main application object for change, before being allowed to update it. A claim made preventing other users from making the same claim, before the application object being released. A main application object could be a Customer, an Order or a Helpdesk Ticket. Such a claim would work like a "check out" in document management systems, or a kind of Semaphore on OS level.
On 15-02-2024 23:11, Tom Blauwendraat wrote:
Closest I could come in finding some info about it is this:
https://github.com/odoo/odoo/pull/87756
Apparently it caused problems and was already long ago removed from the frontend, and by 16.0 they killed the backend part as well.
On 2/15/24 19:07, Sergio Corato wrote:
The logic isn't implemented/enabled in any version that I checked, this seems at least strange (I saw this function working in other softwares decades ago).Debugging didn't help, the context is never passed with the field '__last_update'.
However it's not a requested function, I'll give up for now ;)
Thanks
Sergio Corato
Il giorno gio 15 feb 2024 alle ore 17:07 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:
I also looked for unit tests and didn't find, and also saw this function was deleted in 16.0 (but maybe renamed). I think debugging is the only way to find out! pdb to the rescue
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Tom Blauwendraat - 03:11 - 16 Feb 2024 -
Re: Concurrency write check
From my pov, a simple advice, on the UI with a js, should be enough to point out the fact.Sergio CoratoIl giorno ven 16 feb 2024 alle ore 10:32 Ronald Portier <notifications@odoo-community.org> ha scritto:
So basically Odoo has no longer any mechanism to prevent the changes of one user undoing the changes of another user.
In applications traditionally two mechanisms existed that intended to prevent this problem, respectively pessimistic and optimistic locking.
In pessimistic locking anybody touching a record with the potential to update it, would establish a lock on the record, other users would be prevented from reading the same record for update. This has the potential for lots of access problems, especially as databases and transactions became more complicated and would no longer involve single records but whole networks of records.
Optimistic locking would, as Odoo does, timestamp all records. The idea that most reads that have a potential to update a record, mostly would not be updating anything. But when updating, the timestamp of the record read would be compared with the current timestamp and any previous change would result in an Exception.
An alternative method for optimistic locking, not depending on timestamps, would be to save the original record image and compare with the actual record image just before the actual update.
Missing either pessimistic locking or optimistic locking, for some applications it might be needed to implement a mechanism where a user must specifically claim a main application object for change, before being allowed to update it. A claim made preventing other users from making the same claim, before the application object being released. A main application object could be a Customer, an Order or a Helpdesk Ticket. Such a claim would work like a "check out" in document management systems, or a kind of Semaphore on OS level.
On 15-02-2024 23:11, Tom Blauwendraat wrote:
Closest I could come in finding some info about it is this:
https://github.com/odoo/odoo/pull/87756
Apparently it caused problems and was already long ago removed from the frontend, and by 16.0 they killed the backend part as well.
On 2/15/24 19:07, Sergio Corato wrote:
The logic isn't implemented/enabled in any version that I checked, this seems at least strange (I saw this function working in other softwares decades ago).Debugging didn't help, the context is never passed with the field '__last_update'.
However it's not a requested function, I'll give up for now ;)
Thanks
Sergio Corato
Il giorno gio 15 feb 2024 alle ore 17:07 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:
I also looked for unit tests and didn't find, and also saw this function was deleted in 16.0 (but maybe renamed). I think debugging is the only way to find out! pdb to the rescue
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Sergio Corato - 02:27 - 16 Feb 2024