INODB consistent read view 的实现
2009-8-11 16:52:56 阅读(7) 评论(0)
事务开始时，会首先设置自己可以 view 的事务 ID 的 LIST，涉及源代码如下:
/* No active transaction should be visible, except cr_trx */
while (trx) {
if (ut_dulint_cmp(trx->id, cr_trx_id) != 0
&& (trx->conc_state == TRX_ACTIVE
|| trx->conc_state == TRX_PREPARED)) {
read_view_set_nth_trx_id(view, n, trx->id);
n++;
/* NOTE that a transaction whose trx number is <
trx_sys->max_trx_id can still be active, if it is
in the middle of its commit! Note that when a
transaction starts, we initialize trx->no to
ut_dulint_max. */
if (ut_dulint_cmp(view->low_limit_no, trx->no) > 0) {
view->low_limit_no = trx->no;
}
}
trx = UT_LIST_GET_NEXT(trx_list, trx);
}
view->n_trx_ids = n;
if (n > 0) {
/* The last active transaction has the smallest id: */
view->up_limit_id = read_view_get_nth_trx_id(view, n - 1);
} else {
view->up_limit_id = view->low_limit_id;
}
读取记录时，INNODB 会根据当前事务的ID 来决定取那个版本的数据。
PS 比较简单，之前不了解，把它看得过于神秘了。
寻找更好的模板系统记
2007-9-11 12:47:35 阅读(402) 评论(5)
我一直在搜寻一种模板系统，它的速度要快，功能要强，用起来要比较简单。
一开始，我找到了 django 模板系统。和同类模板系统相比，它的速度是最快的，当然比用 C 写的模板系统稍慢一点，但已经非常不错；功能当然非常强，你甚至可以自己定义语法；用起来确实也非常简单。
但我也有追求效率的毛病，如果存在和 Django 模板系统类似，但比 Django 模板效率更高的模板系统，我会马上移情别恋。
这时，我发现了 Jinja 模板系统，它拥有 Django 模板系统的语法，并且具有更高的执行效率。原因很简单，它将模板代码转换成了可执行的 python 代码，并且有相应的 Cache 策略，速度自然要快很多。
Jinja 系统已经非常不错，但可惜的是，我又发现了 Mako 模板系统，它直接用 Python 代码来书写模板里面的逻辑，和前两种模板系统的哲学(Philosophy)完全不同，它的哲学是:
Python is a great scripting language. Don't reinvent the wheel...your templates can handle it !
作为一个 Pythoner，我完全赞同，Jinja 也被我无情的抛弃了。
综上看来，Mako 才是我的首选，不过问题又来了。经过我观察，在 CGI 中，模板的替换以及结果输出这两部分功能所消耗时间占整个 CGI 处理时间的比重非常的大，通常都占 50% 以上，有的时候甚至更多。我可以优化模板替换部分的效率，但完全没有办法对模板输出部分(IO)的效率进行优化，效率提升空间非常有限。
这的确是很令人沮丧的事。不过我想如果要是有一种 Javascript 的模板系统的话，应该可以解决上面的问题。
于是，借助伟大的 Google， 我又找到了 JST(from trimpath), 它的基本原理是将模板系统转换为实际的 Javascript 代码，和Jinja 的原理类似，只是它是在客户端实现的，生成的是 Javascript 代码而已。不过它的缺点是，模板解析是在客户端进行的，多多少少会影响效率；支持的语法并不太多，和其它的模板系统相比，功能并不算强大，不支持双重循环(可以自己实现)；貌似是我的要求太高了，其实它还是非常优秀非常具有可用性的。
受 Jinja 模板系统的启发，我打算为 Jinja 编写一个 Javascript Translator，可以将模板代码编译为 Javascript 代码。事实上，这是非常可行的，它的官网上也透漏了下一个版本中开发这个 Javascript Translator 的消息。 我很早就开始着手这一 Translator 的编写工作，目前基本可以出一个 demo 了。 Jinja 还是很值得继续关注。
不过我又很快找到了 genshi2js，它可以将 genshi 模板转换为实际 Javascript 代码, 虽然它仅仅支持 xml 格式的模板系统，但我还是很有兴致的试了一试。生成的 js 代码还是非常不错。不过它要依赖一个叫做 MochiKit 的 Js 库，这家伙比较庞大，有 110k 左右(未压缩)，如果可以压缩到 40k 以下的话，还是有一定的可用性的，有待进一步研究。
偶然间，我发现了另外一个 Javascript 模板系统， 他和 Mako 的哲学类似，直接用 Javascript 来写模板的逻辑，它没有名字，因为他实在太小了，仅仅有30行左右，Blog 作者仅仅用一篇 blog 对它进行了介绍，跟贴者无一不说 cool，它就是我想要的。
我找到了理想中的模板系统。
我选择 mootools
2007-9-7 17:38:00 阅读(324) 评论(6)
在开始 Ajax 项目之前，要先选择一个适合的 FrameWork，这样我们的开发会稍微轻松一些，少走很多弯路。眼下 JavaScript 的 FrameWork 可真不少，主要了解过的有 Jquery、Dojo、Yui、Ext、Prototype、Mootools、Njf等，其它未提及的都不在考虑之列。
其中 Dojo、Yui、Ext这三个，下载下来之后就直接被我枪毙了，没有仔细看过，也没有兴趣看；他们的特点是，体积不一般的大，文件不一般的多，大部分文件的代码量都是浩浩荡荡数千行；我被吓住了，我知道我的需求，我不需要这些东西。
用的最多的当属 Njf 了，现在项目中能用到 Ajax 效果的地方真不多，最多不过是动态生成某些元素、层的显示与隐藏、元素的漂移、简单的事件的处理等，比较简单，用 Njf 足够了。Njf 是神崴之做，代码短小精悍，质量更是没得说，看着舒心，用着放心。
不过 Njf 有一个缺点，或者是 Njf 的哲学，它提供的功能太少；一些很普通的功能它都没有，需要你自己来实现，其实网上的代码很多，直接拿过来就可以用了，但是总有一点不爽，这种情况比较多时会令人非常难受；所以，在比较复杂的场合，它也不是最好的选择。
Jquery 和 Prototype 这两个库仅仅是了解了一下，并没有用于实际项目。从他们功能上看，JQuery 更偏向于表现层,而且它与 CSS结合是如此地紧密，以至于可以很方便地控制页面元素；而 Prototype 则更像是 js 的补充功能库；当然二者是有交叉的，只是侧重点不同。
从我个人的理解来看，JQuery 有点走错了方向，Js FrameWork 不应该过分关注表现层的东西，否则会死的很惨；另外在浏览它的代码的时候，发现了两个爆长的函数（估计超过200行），对它的印象大大折扣；Jquery1.1.3 发布的时候，听说速度提升 800%，暴寒，它过去就有那么差吗？
Prototype 非常不错，不过它的代码有 3 千多行，注释非常匮乏，结构显的并不是太清晰，所以读起来也比较头大；虽然如此，在我未发现 Mootools 之前，它仍然是我的首选。
认识 Mootools 是最近的几天的事，在逛 JavaEye 时偶然发现的，当时某位牛人像寻到宝贝一样发了一个标题为强烈推荐 mootools 替代 prototype的文章(文章2)，稍稍关注了下，我就一发不可收拾的爱上它了。
它是一个简洁、模块化、面向对象的 JavaScript 框架。代码结构非常清晰，很具可读性，注释非常全面，有非常完整的文档和特效示例；虽然它也有数千行的代码，但你仍然可以不费力气非常轻松的读懂它。
它与 Prototype 类似，但在模块化方面它要比 Prototype 好很多，功能也要强大很多；
它的下载页面更是酷的要命，你可以选择你要下载的模块和压缩的选项，它会自动的把那些模块合并成一个文件提供给你。
更多功能，请到它的官网了解吧。
所以，我选择了mootools，也强烈建议大家尝试下 Mootools 。
在 Javascript 中，如何创建 mutiline string ?
2007-8-28 17:14:25 阅读(57) 评论(2)
Javascript 对 mutiline string 的支持并不够好，你可以通过字符串的 '\' 或者 '+' 或者其它方法来创建 mutiline string, 但在当字符串比较庞大时，这种方法显的不一般的恶心，基本是无法使用的；相比来讲，Python 的 '"""xxxxx"""' 符号令我们幸福了不少。
当然，在这高度文明的时代，没有做不到，只有想不到，借助伟大的 Google，我似乎找到了答案。
方法一：利用 Javascript 的块注释功能，将庞大的字符串作为一个 Javascript 函数的注释存储起来；使用时，利用简单的文本解析功能即可轻松从这个函数中拿到我们需要的内容，简直太帅了！
不过可惜的是，这种方法仅仅支持 IE， FireFox 根本不会理会 Javascript 注释中的任何内容。
相关文章：文章1、 文章2
方法二：利用 CDATA，将庞大的鱼龙混杂的字符串放进 CDDATA 里面直接赋值给 Javascript 变量，大概的使用方法如下:
var myString = ""+<r><![CDATA[
<div class="pmcb_top">
<div class="pmcb_tabs">
<ul>
<li>Chat</li>
<li>Monks'n'stuff</li>
<li>Other</li>
</ul>
</div>
</div>
]]></r>;
简直太神奇了，我当场佩服的五体投地；唯一可惜的是，IE 并不支持这个伟大的功能，FireFox 用户真幸福！
方法三：不是方法的方法。为同时满足 IE 和 FireFox 用户，我把这段恶毒的字符串仍到 HTML 注释里面，需要的时候用 innerHTML 方法直接提取出来，IE 和 FireFox 都支持这个东西，问题也简单的解决了。
本文章重点不在技术，而在于对 Javascript 程序员想象力的崇拜，再次崇拜一下前两种方法的发明者！