<default></default>
</field>
</declaration>
</table>
now we want the manager to make the necessary alterations, but before i want to mention a possible pitfall. since we renamed the table users to people we also have to change all references to the old name like in the sequence we build. there the reference in the on tag needs to be changed to point to the people table. to achieve this we pass the new and the old version of the schema to the manager. this is why we created a .before file when we first called mdb_manager::updatedatabase(). this ensures that we have an old version of the schema to compare the new version with.
现在我们想要管理器来作出必要的改变，但是在此之前我像提一下可能的陷阱。因为我们把表从 users 更名为 people，我们还需要把所有对原来名字的引用进行更改，比如我们建立的序列。在 on 标签中的索引需要更改为指向 people 表。为了达到这个目的，我们把 shcema 的新旧版本传递给管理器。这酒是为什么我们在第一次调用 mdb_manager::updatedatabase() 时我们创建一个 .before 文件的原因。这确保了我们有一个旧版本的 shcema 来与新的版本进行比照。
$input_file = 'auth.schema';
$manager->updatedatabase($input_file, $input_file.'.before');
that's all! the users table is now called people and now we also have a pwd field.
所有的就是这样！users 表现在称为 people 并且我们也有了一个 pwd 域。
i now want to look at one last feature of the xml schema format. this feature is especially important if you want to programmatically use the manager. imagine that you have several customers that have the same authentication application running on your database server. every customer has a database running on this server with the same schema but one minor difference: the name of the database. while it may be feasible to keep separate schema files for each client because the update cycles will not be the same this is not the case for our sample authentication application. here all clients will be updated at the same time. the xml schema format allows us to use the variable tag for this.
我现在要看看 xml schema 格式的最后一个特性。如果你想要编程性的使用管理器，这个特性尤其重要。假设你有好几个有相同验证程序运行在你的数据库服务器的客户。 每个客户有一个服务器运行在这个服务器有相同的 schema 只有微小的区别：数据库的名字。可能为每个客户单独保存 schema 文件是可行的因为更新周期可能不是一样的，这不是我们例子验证程序的情况。这儿所有的客户同时更新。xml schema 文件允许我们为此可以使用变量。
<?xml version="1.0" encoding="iso-8859-1" ?>
<database>
<name><variable>name</variable></name>
</database>
we can now set the variable name at run time to whatever we may need.
我们现在在运行时设置变量为任意我们需要的东西。
foreach($clients as $name) {
$variables = array('name' => $name)
$manager->updatedatabase($input_file, $input_file.'.before', $variables);
}
the xml schema management is another important piece in the database abstraction concept that mdb provides. it allows us to keep our schema definition independent of a specific rdbms. but using this format also ensures that the correct native data types are used so that mdb can correctly map its native data types. finally, since the format is based on xml it is much easier to write tools that generate or read xml schema files.
xml schema 管理是 mdb 提供的数据库抽象概念的另外一个非常重要的部分。它使得我们保持我们的 schema 定义与特定的 rdbms 无关。但是使用这个格式还确保了使用正确的原生数据类型因而 mdb 能够正确地映射它的原生数据类型。最后，因为数据是基于 xml 的，编写产生或者读取 xml schema 文件的工具要容易一些。
sounds great but my application already uses ...
听起来不错但是我的应用程序已经使用了……
most readers probably find themselves in a position where they already have a number of applications that run on some other database abstraction layer. due to mdb's heritage most pear db users should find that mdb feels very similar, since the api of mdb is based on that of pear db. metabase users should find that all their favourite functions have their counterpart in mdb. the xml schema format is exactly the same as in metabase. a complete guide to porting your existing applications to mdb is beyond the scope of this article, instead i will use this space to give some tips. if you have any specific questions feel free to email me.
大部分读者可能发现它们处于这样的境地——他们已经有了大量运行于其他数据库抽象层的程序。由于 mdb 的出身，大部分 pear db 的用户应当发现 mdb 感觉上非常类似，因为 mdb 的 api 是基于 pear db 的。metabase 用户应当发现他们所有偏爱的功能都在 mdb 中有对应的东西。xml schema 格式和 metabase 中的是一摸一样的。一个完全的指导来引导你把已经写好的程序移植到 mdb 中超出了本文的范围，但是我将利用这个机会给一些提示。如果你有任何具体的问题，放心的发信来询问我。
to port your pear db application to mdb the best place to start is the pear wrapper. for one you can run your application using the pear wrapper. the wrapper of course does add a little bit of overhead so you will probably want to port to the native interface at some point. the first step then should be listing all pear db methods that your application currently uses. then look at the wrapper for any differences in the api. there are two key differences you will notice: result sets are not objects anymore and all of the querying methods allow you to pass the data types of the result set which will result in slight changes in the parameter order. the first difference means that instead of calling the fetch method on the result object:
