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

[Jeff Kowalczyk]

--- Mike Fedyk <mfedyk at mikefedyk.com> wrote:
> >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.

http://forums.vtiger.com/viewtopic.php?t=1439&highlight=adodb+schema

Mike may have made more recent patches than this.

> >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?

Not mscrm. ADO.net I remember clearly had good support for only updating
changed columns in changed rows when you recordset.update()'d. The progentior
microsoft adodb library (later versions) had something similar, I seem to
recall.

It happens at the library layer (or at least is coordinated with ODDBC/DTC by
that layer), so our php-adodb would be in scope to provide the same feature, if
it does.

> >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.

I would consider any update behaviour beside that a bug, and a potentially
dangerous one at that. Is it this way all over vtiger?

> > 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?

A fair point, I had never considered the user on a shared php account (as
opposed to a virtual host). I would think that the crm database of any
profitable business would be way too valuable to risk on a shared account, but
I'm sure it happens, and it should be supported.

> 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.

Does PHP allow import (require, whatever they call it) success testing, and in
failure case, specifying the path to import from? If so, then how about:

- an import statement that specifies a minimum version of adodb, to be found in
the php system path. Optionally define a maximum version, if vtigercrm is known
incompatible with a very new version of adodb.

- If that fails, then import from local path vtigercrm/adodb bundled copy,
which happens to be the latest adodb release version which passes QA testing
(however that's defined).

This way you don't have to support many versions of adodb (usually 1-2), but
the sysadmin can run a newer version if they want to.

> Just because it hasn't been update often enough to your liking
> doesn't mean we can't update it more often.

The snapshotted version at the time was 4.55, and many vtigercrm
database-related bugs, particularly sql-injection, were being fixed. It seemed
wise to push for an adodb upgrade that had already specifically addressed
sql-injection, among other security concerns.

The new versions of adodb also had implications on postgresql and other DBMS
support, improvements to cross-database SQL generation, and schema migration
support, all of which where priorities to someone.

http://phplens.com/lens/adodb/docs-adodb.htm#changes

> Also a middle-ground may be to just have a variable that 
> specifies the location of adodb and default to the one included with vtiger.

A workable alternative to the import scheme described above. Its fine by me if
the path to all dependencies and bundled snapshots are specified with defaults
in the config file. I think we have the same situation with Smarty templates
now, too.

> 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.

This was for the branch to add postgresql support in time to get it into 4.2.x
(3, I think). Perhaps patching adodb would not have been necessary with the dev
process improvements happening here in the last week. I expect patching adodb
will be rare. If a minor tweak has to be done to get a release out, no harm I
guess.

> Let's keep adodb in the vtiger source code.

There are so many other things that are likely to get better now, I don't even
mind if they do. ;)

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com