我心里一直有个疑问，收到订单后，Magento 是怎么更新库存数量的？是直接用一个新库存数字去更新，还是用 upadte magento_cataloginventory_stock_item set qty=qty-qty_ordered 之类的办法。 通过跟踪 sql 语句，我感觉前者的可能性很大。 这样很不好，如果几个人同时买同一个产品，会搞乱库存数。不知道被破坏的几率有多大，有空要搞一个并发下单的测试。
Tag: mysql
Mysql varchar could be transformed to memo in Ms Access
Mysql varchar could be transformed to memo in Ms Access when Mysql table is used as linked table inside Access, but I want to prevent this from happening. Mainly because I can not join tables with memo field. As I observed, long Mysql varchar field is transformed to memo field, but short one stays as… Continue reading Mysql varchar could be transformed to memo in Ms Access
Magento database fetch mode
I was used to write $modelName->column_name to get attribute value in database. It requires $resource->_getReadAdapter()->setFetchMode(Zend_Db::FETCH_OBJ);. However, it is not Magento’s default fetch mode (default is Zend_Db:FETCH_ASSOC). Whenever fetch mode is changed, it must be changed back to the default after using it. Otherwise, method getCollection() of ALL models will stop working. There may be other… Continue reading Magento database fetch mode
mysql_update
When using phpmyadmin, after select a database, then click on Privileges, you might run into a error saying Unknown column ‘Event_priv’ in ‘field list’ The error will go after you run mysql_upgrade in command line. I feel mysql query speed is improved after running “mysql_update”.
Speed bottleneck of the web server
非常典型的多层架构： 第一层 Nginx 第二层 php fastcgi 第三层 memcached 第四层 MySql Apache 有个 mod_php，相当于合并了第一层和第二层，Nginx 没有 module for php，这不是什么问题，分层更利于扩展。第三层的加入完全是为了减轻数据库压力，提高性能。目前第2，3，4层之间的优化差不多到极限了（或者说到我能力的极限了），但第1，2层之间尚有潜力可挖。 not_in_use.php 和 not_in_use.html 都是一个静态文件，没有数据库操作。但 php 文件必须由 Nginx 经由 php fastcgi （使用 unix socket）产生，html 则由 Nginx 直接访问文件系统，就单因素分析，php fastcgi 是普通文件系统速度的34%，所以要想办法绕开 php fastcgi。以下测试在数据中心主机上直接运行 ApacheBench。 测试一： $ ab -kc 100 -n 500 http://magento/not_in_use.php This is ApacheBench, Version 2.0.40-dev apache-2.0 Copyright 1996 Adam… Continue reading Speed bottleneck of the web server
Zend_Db ignore default charset of Mysql
While I set my Mysql database default character set as UTF-8, Zend_Db_Adapter does not pick up the setting. Zend_Db write to Mysql using its own default character set (I guess it’s ISO-8859-1), unless it is specifically told by $dbAdapter->query(“SET NAMES ‘utf8′”); before Zend_Db_Table::setDefaultAdapter($dbAdapter);
Quick access to data for both internet and intranet users
我曾思考过，也不止一次被人问过：数据中心的数据如何可以被公司员工快速存取？Internet users（客户、供应商、合作伙伴）通常存取单条数据，数据中心与internet users之间的传输速度足够满意；但intranet users（员工）经常存取批量数据，一般的宽带会让intranet users在存取数据时有大量的时滞。 难道在intranet建数据中心？小公司是负担不起的，最起码ADSL就得撤换成SDSL甚至更快的专线，最低档的SDSL（2M）也比ADSL贵十倍。在专业的数据中心可以以很低的成本实现100M到桌面，如果要不牺牲internet user experience，买条100M的专线，那是天价。 在成本不上升的情况下，如何让internet和intranet用户同时能快速访问数据？我曾想过Ajax，但觉得Ajax不是好的方案，因为Ajax只能缓解intranet users在等待数据时的焦虑心理，数据传输速度没有得到改善；我还想过分解数据表，把internet users经常用到的数据放在数据中心，把intranet suers经常用到的数据放在本地，但总有一些数据是双方都经常用到的，很难权衡该放在哪一端；而且对于一个现成的系统，分解数据表似乎不太现实。 今天我很高兴，因为我发现MySQL早就内置了数据同步功能（只是我孤陋寡闻罢了），只要几步简单设置，一个复杂的internet / intranet 矛盾就解决了，幸好我还没有走入Ajax和分解数据表的歧路。 做事一定要站得高看得远啊，这也是我说“多找软件、用好软件”的初衷。
Workaround to row cannot be located for updating
用ADO + ODBC操作Mysql database，用起来总不顺手。经常有莫名其妙的错误，其中不乏connector bugs。这些bugs不是我等能解决的，只有尽量不去触发bugs才是上策。 比如，我今天在使用recordset.update时被提示”Row cannot be located for updating. Some values may have been changed since it was last read.” 我排错了好久，最后总结出以下best practices: 避免使用”SELECT *”来查询，用到哪些字段就SELECT那些字段； 如果SELECT中的字段中，某些值没有改变，recordset.update 可能会出错（也就是说，所有字段值都被改变后才能update） Connector/ODBC Application Specific Tips特别提到Access can’t always handle the MySQL DATE column properly. If you have a problem with these, change the columns to DATETIME. Float或double类型字段值，避免用Float或Double运算后的值直接去更新，应该保留必要精度后的值去更新。例如，x和y都是double类型，total字段也是double类型，不要用x+y去更新total字段，若total只要保留两位小数，就用formatnumber(x+y, 2)去更新total。 综上，为了简单起见，如果要update… Continue reading Workaround to row cannot be located for updating