[Vtigercrm-developers] [vtigercrm-developers] Re: Has anyone addressed this data overwriting issue?

Mike Fedyk mfedyk at mikefedyk.com
Fri Feb 3 18:03:26 PST 2006


Jeff Kowalczyk wrote:

>Mike Fedyk wrote:
>  
>
>>It may be more trouble than it's worth because vtiger can't really know 
>>when a user has stopped editing a record.  Comments wanted.
>>http://forums.vtiger.com/viewtopic.php?p=19700#19700
>>    
>>
>>>Record locking doesn't seem to be implemented.
>>>      
>>>
>
>adodb doesn't implement some sort of recordset-aware update? Have any of
>the adodb experts reviewed whether vtigercm is using the library to the
>extent of its capabilities? I know Mike Crowe has a lot of adodb schema
>infrastructure that he wanted to get in.
>  
>

I want to see this code.  I'm not familiar with adodb right now and if 
there are bug reports we should be able to get this in if it isn't too 
intrusive.

>The microsoft namesake accepted a full row of data for update, compared
>each column against the versions when the recordset was opened, and issued
>an UPDATE sql statement for only the fields that were different locally in
>that recordset,
>  
>

Is this in the mssql client code or done by the server?  Are you talking 
about mscrm?

>This meant that last committer on a given field wins, but if you didn't
>change a field in your form, you weren't going to write that column, or be
>affected if it changed while your recordset was open.
>  
>

Yes, I was thinking about something just like this for vtiger.

>FWIW, postgresql has MVCC, which does a related thing during the commit
>phase of the transacted update SQL statement. This helps with lock
>contention:
>
>http://www.google.com/search?q=postgresql+mvcc 
>
>
>http://phplens.com/adodb/reference.functions.getupdatesql.html#getupdatesql
>
>GetUpdateSQL(&$rs, $arrFields, $forceUpdate=false,$magicq=false,$forcenulls=false)
>
>Generate SQL to update a table given a recordset $rs, and the modified
>fields of the array $arrFields (which must be an associative array holding
>the column names and the new values) are compared with the current
>recordset. If $forceUpdate is true, then we also generate the SQL even if
>$arrFields is identical to $rs->fields. Requires the recordset to be
>associative. $magicq is used to indicate whether magic quotes are enabled
>(see qstr()).
>
>Since 4.52, we allow you to pass the $force type parameter, and this
>overrides the $ADODB_FORCE_TYPE global variable.
>
>Since 4.62, the table name to be used can be overridden by setting
>$rs->tableName before AutoExecute(), GetInsertSQL() or GetUpdateSQL() is
>called. 
>
>
>(BTW, this is reason #326 that we need to stop bundling a snapshot of
>adodb, and check for it as an external dependency.)
>  
>

Not true.  One of the great things about vtiger is that it is so damn 
easy to install on one of those cheap $5 shared php hosting plans.  All 
you need is php, mysql and gd on the server and that is *very* common.  
How many provide adodb?

Also, you would have to support old versions of adodb and couldn't use 
the features from the new versions unless you tested for the right 
version before-hand.  Do you want that?  At least you know what version 
to program for when it is in the codebase.  Just because it hasn't been 
update often enough to your liking doesn't mean we can't update it more 
often.  Also a middle-ground may be to just have a variable that 
specifies the location of adodb and default to the one included wit vtiger.

One more thing.  You wouldn't be able to patch adodb anymore.  I forget 
who it was, but they wanted adodb out of the codebase but not until a 
postgres feature was merged upstream.

Let's keep adodb in the vtiger source code.

>
>
>http://phplens.com/lens/adodb/tips_portable_sql.htm
>
>Selects: Locking
>
>SELECT statements are commonly used to implement row-level locking of
>tables. Other databases such as Oracle, Interbase, PostgreSQL and MySQL
>with InnoDB do not require row-level locking because they use versioning
>to display data consistent with a specific point in time.
>
>Currently, I recommend encapsulating the row-level locking in a separate
>function, such as RowLock($table, $where):
>
>$connection->BeginTrans( );
>
>$connection->RowLock($table, $where); 
>
># some operation
>
>if ($ok) $connection->CommitTrans( );
>
>else $connection->RollbackTrans( );
>  
>
Are we even using transactions right now in vtiger 4.2.x?



More information about the vtigercrm-developers mailing list