Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Usage on ZYXEL NAS: INNODB mandatory?
#1
Question 
Just tried this, because using ENGINE=INNODB throws 'Can't create' error:

Code:
CREATE TABLE IF NOT EXISTS `vtiger_cbupdater` (
 `cbupdaterid` int(11) NOT NULL DEFAULT '0',
 `cbupd_no` varchar(26) DEFAULT NULL,
 `author` varchar(83) DEFAULT NULL,
 `filename` varchar(218) DEFAULT NULL,
 `pathfilename` varchar(218) DEFAULT NULL,
 `classname` varchar(183) DEFAULT NULL,
 `execstate` varchar(56) DEFAULT NULL,
 `systemupdate` varchar(3) DEFAULT NULL,
 `blocked` varchar(3) DEFAULT NULL,
 `perspective` varchar(3) DEFAULT NULL,
 `execdate` date DEFAULT NULL,
 `execorder` int(11) DEFAULT NULL,
 PRIMARY KEY (`cbupdaterid`),
 UNIQUE KEY `findupdate` (`filename`,`classname`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Bummer too. Error: 1071 SQLSTATE: 42000 (ER_TOO_LONG_KEY)

(Problem: ZYXEL doesn't support INNODB in it's mySQL packages yet)

Any idea?

Best regards
[list]
[*]vtiger 5.21:      Ubuntu 12.04LTS on INTEL, Zyxel NSAs 325v2, 540 on ARM
[*]CoreBOS 5.5:   Ubuntu 12.04LTS on INTEL, Zyxel NSAs 325v2, 540 on ARM
[*]Dolibarr 3.8.x:  Ubuntu 12.04LTS on INTEL, Zyxel NSAs 325v2, 540 on ARM
[/list]
Reply
#2
This is going to be complicated in general. I really don't know the full implications of not using INNODB, for sure it will be slower and some internal database restrictions will not be imposed (not really a problem).
In the case of the unique key that is giving you a problem in cbupdater you can just eliminate that key, it will simply be slower but cbupdater doesn't really have a lot of records so you should be ok.

The conflicting key is: UNIQUE KEY `findupdate` (`filename`,`classname`)
Joe
TSolucio
Reply
#3
Thks. This worked!

Now the related question - because Calendar4You (also depending on InnoDB) doesn't work either (in this limited environment):

Could it make sense to 'sed' convert the 'ENGINE=InnoDB' (after GIT cloning) locally?

And would it be a good idea (in the long term) to branch out such a version of the complete  CoreBOS?

Or do you (or other members of the core developer team) expect future developments, which can't be integrated using MyISAM?

The reason I'm asking: I suppose there is a bunch of SMBs or SOHOs whose usage pattern resembles mostly a 2/8/16 hour use of such systems (2 hours total access of Corebos (in short stints) during an 8 hour workday - while switching off the NAS for 16 hours afterwards).

Best regards
[list]
[*]vtiger 5.21:      Ubuntu 12.04LTS on INTEL, Zyxel NSAs 325v2, 540 on ARM
[*]CoreBOS 5.5:   Ubuntu 12.04LTS on INTEL, Zyxel NSAs 325v2, 540 on ARM
[*]Dolibarr 3.8.x:  Ubuntu 12.04LTS on INTEL, Zyxel NSAs 325v2, 540 on ARM
[/list]
Reply
#4
I have been reading up on the MyISAM vs InnoDB engines. In general for what coreBOS does and, specially in an environment as you indicate of very low usage and data you will be safe using either. That said, InnoDB is better, not only because it is safer against crashes and supports transactions (faster) but because it permits establishing relations (foreign keys) which are interesting for a relational application like coreBOS.

Your real problem will not be as much in the application, which you can fork and adapt as you need, but with other external modules where each one can define the tables as they please, so you would have to end up forking and patching those too if you have access to the code.

Just a quick example that comes to mind would be the coreBOS Employee module:

https://github.com/tsolucio/coreBOSEmployee/blob/master/manifest.xml#L89
Joe
TSolucio
Reply


Forum Jump:


Users browsing this thread: 4 Guest(s)