📄 34to35.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head><title>SQLite Changes From Version 3.4.2 To 3.5.0</title><style type="text/css">body { margin: auto; font-family: "Verdana" "sans-serif"; padding: 8px 1%;}a { color: #45735f }a:visited { color: #734559 }.logo { position:absolute; margin:3px; }.tagline { float:right; text-align:right; font-style:italic; width:240px; margin:12px; margin-top:58px;}.toolbar { font-variant: small-caps; text-align: center; line-height: 1.6em; margin: 0; padding:1px 8px;}.toolbar a { color: white; text-decoration: none; padding: 6px 12px; }.toolbar a:visited { color: white; }.toolbar a:hover { color: #80a796; background: white; }.content { margin: 5%; }.content dt { font-weight:bold; }.content dd { margin-bottom: 25px; margin-left:20%; }.content ul { padding:0px; padding-left: 15px; margin:0px; }/* rounded corners */.se { background: url(images/se.png) 100% 100% no-repeat #80a796}.sw { background: url(images/sw.png) 0% 100% no-repeat }.ne { background: url(images/ne.png) 100% 0% no-repeat }.nw { background: url(images/nw.png) 0% 0% no-repeat }</style><meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head><body><div><!-- container div to satisfy validator --><a href="index.html"><img class="logo" src="images/SQLite.gif" alt="SQLite Logo" border="0"></a><div><!-- IE hack to prevent disappearing logo--></div><div class="tagline">Small. Fast. Reliable.<br>Choose any three.</div><table width=100% style="clear:both"><tr><td> <div class="se"><div class="sw"><div class="ne"><div class="nw"> <div class="toolbar"> <a href="about.html">About</a> <a href="sitemap.html">Sitemap</a> <a href="docs.html">Documentation</a> <a href="download.html">Download</a> <a href="copyright.html">License</a> <a href="news.html">News</a> <a href="http://www.sqlite.org/cvstrac/index">Developers</a> <a href="support.html">Support</a> </div></div></div></div></div></td></tr></table> <h1> Moving From SQLite 3.4.2 to 3.5.0</h1><p> SQLite version 3.5.0 introduces a new OS interface layer that is incompatible with all prior versions of SQLite. In addition, a few existing interfaces have been generalized to work across all database connections within a process rather than just all connections within a thread. The purpose of this article is to describe the changes to 3.5.0 in detail so that users of prior versions of SQLite can judge what, if any, effort will be required to upgrade to newer versions.</p><h2>1.0 Overview Of Changes</h2><p> A quick enumeration of the changes in SQLite version 3.5.0 is provide here. Subsequent sections will describe these changes in more detail.</p><p> <ol> <li>The OS interface layer has been completely reworked: <ol type="a"> <li>The undocumented <b>sqlite3_os_switch()</b> interface has been removed.</li> <li>The <b>SQLITE_ENABLE_REDEF_IO</b> compile-time flag no longer functions. I/O procedures are now always redefinable.</li> <li>Three new objects are defined for specifying I/O procedures: <a href="c3ref/vfs.html">sqlite3_vfs</a>, <a href="c3ref/file.html">sqlite3_file</a>, and <a href="c3ref/io_methods.html">sqlite3_io_methods</a>.</li> <li>Three new interfaces are used to create alternative OS interfaces: <a href="c3ref/vfs_find.html">sqlite3_vfs_register()</a>, <a href="c3ref/vfs_find.html">sqlite3_vfs_unregister()</a>, and <a href="c3ref/vfs_find.html">sqlite3_vfs_find()</a>.</li> <li>A new interface has been added to provided additional control over the creation of new database connections: <a href="c3ref/open.html">sqlite3_open_v2()</a>. The legacy interfaces of <a href="c3ref/open.html">sqlite3_open()</a> and <a href="c3ref/open.html">sqlite3_open16()</a> continue to be fully supported.</li> </ol></li> <li>The optional shared cache and memory management features that were introduced in version 3.3.0 can now be used across multiple threads within the same process. Formerly, these extensions only applied to database connections operating within a single thread. <ol type="a"> <li>The <a href="c3ref/enable_shared_cache.html">sqlite3_enable_shared_cache()</a> interface now applies to all threads within a process, not to just the one thread in which it was run.</li> <li>The <a href="c3ref/soft_heap_limit.html">sqlite3_soft_heap_limit()</a> interface now applies to all threads within a process, not to just the one thread in which it was run.</li> <li>The <a href="c3ref/release_memory.html">sqlite3_release_memory()</a> interface will now attempt to reduce the memory usages across all database connections in all threads, not just connections in the thread where the interface is called.</li> <li>The <a href="c3ref/aggregate_count.html">sqlite3_thread_cleanup()</a> interface has become a no-op.</li> </ol></li> <li>Restrictions on the use of the same database connection by multiple threads have been dropped. It is now safe for multiple threads to use the same database connection at the same time.</li> <li>There is now a compile-time option that allows an application to define alternative malloc()/free() implementations without having to modify any core SQLite code.</li> <li>There is now a compile-time option that allows an application to define alternative mutex implementations without having to modify any core SQLite code.</li> </ol></p><p> Of these changes, only 1a and 2a through 2c are incompatibilities in any formal sense. But users who have previously made custom modifications to the SQLite source (for example to add a custom OS layer for embedded hardware) might find that these changes have a larger impact. On the other hand, an important goal of these changes is to make it much easier to customize SQLite for use on different operating systems. </p><h2>2.0 The OS Interface Layer</h2><p> If your system defines a custom OS interface for SQLite or if you were using the undocumented <b>sqlite3_os_switch()</b> interface, then you will need to make modifications in order to upgrade to SQLite version 3.5.0. This may seem painful at first glance. But as you look more closely, you will probably discover that your changes are made smaller and easier to understand and manage by the new SQLite interface. It is likely that your changes will now also work seamlessly with the SQLite amalgamation. You will no longer need to make any changes to the code SQLite source code. All of your changes can be effected by application code and you can link against a standard, unmodified version of the SQLite amalgamation. Furthermore, the OS interface layer, which was formerly undocumented, is now an officially support interface for SQLite. So you have some assurance that this will be a one-time change and that your new backend will continue to work in future versions of SQLite.</p><h3>2.1 The Virtual File System Object</h3><p> The new OS interface for SQLite is built around an object named <a href="c3ref/vfs.html">sqlite3_vfs</a>. The "vfs" stands for "Virtual File System". The sqlite3_vfs object is basically a structure containing pointers to functions that implement the primitive disk I/O operations that SQLite needs to perform in order to read and write databases. In this article, we will often refer a sqlite3_vfs objects as a "VFS".</p><p> SQLite is able to use multiple VFSes at the same time. Each individual database connection is associated with just one VFS. But if you have multiple database connections, each connection can be associated with a different VFS.</p><p> There is always a default VFS. The legacy interfaces <a href="c3ref/open.html">sqlite3_open()</a> and <a href="c3ref/open.html">sqlite3_open16()</a> always use the default VFS. The new interface for creating database connections, <a href="c3ref/open.html">sqlite3_open_v2()</a>, allows you to specify which VFS you want to use by name.</p><h4>2.1.1 Registering New VFS Objects</h4><p> Standard builds of SQLite for unix or windows come with a single VFS named "unix" or "win32", as appropriate. This one VFS is also the default. So if you are using the legacy open functions, everything will continue to operate as it has before. The change is that an application now has the flexibility of adding new VFS modules to implement a customized OS layer. The <a href="c3ref/vfs_find.html">sqlite3_vfs_register()</a> API can be used to tell SQLite about one or more application-defined VFS modules:</p><blockquote><pre>int sqlite3_vfs_register(sqlite3_vfs*, int makeDflt);</pre></blockquote><p> Applications can call sqlite3_vfs_register at any time, though of course a VFS needs to be registered before it can be used. The first argument is a pointer to a customized VFS object that the application has prepared. The second argument is true to make the new VFS the default VFS so that it will be used by the legacy <a href="c3ref/open.html">sqlite3_open()</a> and <a href="c3ref/open.html">sqlite3_open16()</a> APIs. If the new VFS is not the default, then you will probably have to use the new <a href="c3ref/open.html">sqlite3_open_v2()</a> API to use it. Note, however, that if a new VFS is the only VFS known to SQLite (if SQLite was compiled without its usual default VFS or if the pre-compiled default VFS was removed using <a href="c3ref/vfs_find.html">sqlite3_vfs_unregister()</a>) then the new VFS automatic becomes the default VFS regardless of the makeDflt argument to <a href="c3ref/vfs_find.html">sqlite3_vfs_register()</a>.</p><p> Standard builds include the default "unix" or "win32" VFSes. But if you use the -DOS_OTHER=1 compile-time option, then SQLite is built without a default VFS. In that case, the application must register at least one VFS prior to calling <a href="c3ref/open.html">sqlite3_open()</a>. This is the approach that embedded applications should use. Rather than modifying the SQLite source to to insert an alternative OS layer as was done in prior releases of SQLite, instead compile an unmodified SQLite source file (preferably the amalgamation) with the -DOS_OTHER=1 option, then invoke <a href="c3ref/vfs_find.html">sqlite3_vfs_register()</a> to define the interface to the underlying filesystem prior to creating any database connections.</p><h4>2.1.2 Additional Control Over VFS Objects</h4><p> The <a href="c3ref/vfs_find.html">sqlite3_vfs_unregister()</a> API is used to remove an existing VFS from the system.</p><blockquote><pre>int sqlite3_vfs_unregister(sqlite3_vfs*);</pre></blockquote><p> The <a href="c3ref/vfs_find.html">sqlite3_vfs_find()</a> API is used to locate a particular VFS by name. Its prototype is as follows:</p><blockquote><pre>sqlite3_vfs *sqlite3_vfs_find(const char *zVfsName);</pre></blockquote><p> The argument is the symbolic name for the desired VFS. If the argument is a NULL pointer, then the default VFS is returned. The function returns a pointer to the <a href="c3ref/vfs.html">sqlite3_vfs</a> object that implements the VFS. Or it returns a NULL pointer if no object could be found that matched the search criteria.</p><h4>2.1.3 Modifications Of Existing VFSes</h4><p>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -