0001638: WAD generated code allows dirty writes - Openbravo Issue Tracking System

Notes
(0001589) villind (developer) 2007-07-26 17:25 edited on: 2008-06-12 09:20	Logged In: YES user_id=61737 Originator: YES The detection of a dirty write can be done by adding a "AD_version" column in the tables and that is incremented by each write. While writing the code must use the existing version in the WHERE clause and check that the affected rows was more than 0.

(0001590) villind (developer) 2007-07-26 18:21 edited on: 2008-06-12 09:20	Logged In: YES user_id=61737 Originator: YES Actually the version number can also enable automatic audit trail for these tables. * Add a table which is a copy of the original, except the name an primary key also includes the version number. * Add an update trigger that copies data to this table whenever the original is updated.

(0001591) psarobe (manager) 2007-09-03 19:13 edited on: 2008-06-12 09:20	Logged In: YES user_id=1500703 Originator: NO This is not a bug, this should be a feature request. Thank you very much

(0001592) villind (developer) 2007-09-04 08:44 edited on: 2008-06-12 09:20	Logged In: YES user_id=61737 Originator: YES This is a bug to anyone who is using Openbravo for serious business. Currently I would not advise anyone to use it if there are more than one person taking care of one function in a company. Even if this is not a implementation bug this is serious design flaw. There have been similar design issues that result implementations that implementation that _destroys_data_, and in most cases those have been accepted as bug reports. I can pull the feature request side apart from this ticket and add it as a feature request, but let's keep the _data_destruction_ side as a bug report. In my opinion, this should be listed somewhere where it is visible to possible users. It may be in open bugs list or known issues list, but definitely not just a feature request. Ville

(0001593) plujan (manager) 2007-09-04 10:38 edited on: 2008-06-12 09:20	Logged In: YES user_id=1759992 Originator: NO Hi Ville, You are right, there are not write locking policies in the current OpenbravoERP version. The design for next version provides native support for write lockings, so no dirty writes will be produced. You may check the roadmap we are working out at the wiki. I understand your concern about data destruction, and I agree it is important, but in our ERP implementations (with real end-users making real use of functionallity) there were not data overwriting. Regards, Pablo.

(0001594) plujan (manager) 2007-09-04 10:39 edited on: 2008-06-12 09:20	Logged In: YES user_id=1759992 Originator: NO Hi Ville, You are right, there are not write locking policies in the current OpenbravoERP version. The design for next version provides native support for write lockings, so no dirty writes will be produced. You may check the roadmap we are working out at the wiki. I understand your concern about data destruction, and I agree it is important, but in our ERP implementations (with real end-users making real use of functionallity) there were not data overwriting. Regards, Pablo.

(0001595) villind (developer) 2007-09-04 11:09 edited on: 2008-06-12 09:20	Logged In: YES user_id=61737 Originator: YES Hi, the problem is that with the current implementation the Openbravo does not detect that there is any data overwriting. As the normal users believe that computer systems sometimes loose some data and do other "weird" things it is not easy to detect this kind of issues in real life before they do serious damage. I agree that the native and the fancy implementation with conflict resolution should go to the "Green version" but Openbravo 2.x should at least detect and prevent this from happening. The easiest way to implement this would be just by adding modified(or was it update) time in where clause for WAD generated code and check that the save result affects exactly the number of rows that are expected. But if the decision is no for Openbravo 2.x then we need to do this. Ville

(0001596) pjuvara (reporter) 2007-10-30 15:58 edited on: 2008-06-12 09:20	Logged In: YES user_id=1871571 Originator: NO Reopening this bug. Regardless on when it gets implemented, we cannot argue that this is not a bug.

(0001597) alostale (manager) 2008-05-21 11:34 edited on: 2008-06-12 09:20	Logged In: YES user_id=1500722 Originator: NO This bug is rejected and will be taken into account for the new data access layer definition

(0001598) alostale (manager) 2008-05-26 09:28 edited on: 2008-06-12 09:20	Logged In: YES user_id=1500722 Originator: NO A feature request to fix it has been opened: https://issues.openbravo.com/view.php?id=424 [^]

(0005227) user71 2005-06-01 00:00 edited on: 2008-06-12 09:43	This bug was originally reported in SourceForge bug tracker and then migrated to Mantis. You can see the original bug report in: https://sourceforge.net/support/tracker.php?aid=1761346 [^]

Issue History
Date Modified	Username	Field	Change

Relationships [ Relation Graph ] [ Dependency Graph ]