[Vtigercrm-developers] 4.2.4 installer creates tables as MyISAM

[Mike Fedyk]

Jeff Kowalczyk wrote:

>Mike Fedyk wrote:
>  
>
>>Ok, we have a modified adodb in vtiger 4.2.3.
>>    
>>
>
>I sympathize for any breakage that might result from my adodb updates, and
>have tried to make them single-commit to ease reverts if needed.
>
>My goal has been to find out to where vtigercrm deviates from production
>adodb (currently adodb-4.72) and reduce the question of bundling vs
>external dependency to a minimum diff needed to run.
>
>  
>
>>It allows you to specify <opt>Type=InnoDB</opt> in the XML file. And
>>updating adodb breaks that.
>>    
>>
>
>Is the use of InnoDB storage necessary for mysql operation, or was it just
>a performance-seeking choice?
>  
>

Do you want transactions?
Do you want versioned updates like in postgres?
Do you want journaled writes?
Do you want foreign key constraints?

Yes we need InnoDB with mysql.

>Since being acquired by Oracle, InnoDB's availability for future
>open-source mysql versions is in some question. I would view any InnoDB
>dependency as a bug. Especially if it were only an incremental performance
>motivation.
>
>  
>

InnoDB is released under the GPL.  I see the news of Oracle buying 
InnoDB as only a concern for mysql the company when it sells InnoDB 
under non-GPL licenses. 

In fact, as far as licenses are concerned, Postgres is more vulnerable 
to being bought by a commercial company than Mysql/InnoDB.  At least 
with the GPL you know they can't make a non-public fork and distribute 
it without also distributing the code.

Postgres may blow Mysql away in feature support, but vulnerability to 
being bought out is not one of Mysql's weak points.  Next.

>What does that <opt> information do to postgresql and other backend
>compatibility? Since the team was focused only on mysql, the custom <opt>
>may be totally in opposition to our cross-database objectives.
>
>  
>
I have no idea.  I think we should ask for input from the adodb developers.

>>We're either going to have to revert or port the changes. What does 
>>everyone think?
>>    
>>
>
>I think we're going to find that few distros will consider vtigercrm as
>having met their packaging standards if we have a bundled adodb
>that can't be removed in favor of a system-packaged version during
>packaging.
>
>If we stay on that route, it must be a well-considered decision to take on
>the responsibility of shipping a private copy of a database library. Any
>adodb security issues that linger unpatched will reflect poorly on
>vtigercrm.
>  
>
We're already in that boat.  I can see updating adodb once it doesn't 
break our current setup as a long term goal for 4.2, but we may have to 
revert to the previous version for this release.

I'm going to try porting the <opt> changes to the latest adodb, but if 
we can't get this working before rc1 comes out (that's 1 day folks) it's 
going to have to be reverted.

Any help on the porting would be appreciated.

Mike