扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
据印象,firefox4版本之前开始就向w3c组织提交了收集到的大量的针对IndexedDB规范的重要反馈资料,并且在firefox4中开始予以支持。至于类型,火狐内置的数据库是sqlite,纯...
创新互联于2013年创立,是专业互联网技术服务公司,拥有项目成都网站建设、成都网站设计网站策划,项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命,1280元怀安做网站,已为上家服务,为怀安各地企业和个人服务,联系电话:13518219792
create table t
(
id int,
sqlite varchar(2000)
)
insert into t(id ,sqlite ) values (1,'你好SQL');
insert into t(id ,sqlite ) values (2,'再见地球');
insert into t(id ,sqlite ) values (3,'创世纪Genisis');
insert into t(id ,sqlite ) values (4,'SELECT语句');
insert into t(id ,sqlite ) values (5,'SELECT');
CREATE FUNCTION [dbo].[fz]
(
@s varchar(2000) =''
)
returns varchar(2000)
as
begin
if ascii(@s) is null
return ''
IF ascii(left(@s,1))123
begin
declare @i int
set @i = 1
declare @ss varchar(100)
set @ss =SUBSTRING (@s,@i,1)
while (ASCII (@ss)123)
begin
set @i=@i+1
set @ss=SUBSTRING (@s,@i,1)
end
return substring(@s,1,@i-1)
end
IF ascii(left(@s,1))=123 and ascii(left(@s,1))0
BEGIN
declare @j int
set @j = 1
declare @sa varchar(1000)
set @sa =SUBSTRING (@s,@j,1)
while (ASCII (@sa)=123)
begin
set @j=@j+1
set @sa=SUBSTRING (@s,@j,1)
end
return substring(@s,1,@j-1)
end
return @s
end
go
select ID,sqlite,dbo.fz(sqlite) as 汉字部分,REPLACE (sqlite,dbo.fz(sqlite),'') 英文部分 from t
Cgo 使得Go程序能够调用C代码. cgo读入一个用特别的格式写的Go语言源文件, 输出Go和C程序, 使得C程序能打包到Go语言的程序包中.
举例说明一下. 下面是一个Go语言包, 包含了两个函数 -- Random 和 Seed -- 是C语言库中random和srandom函数的马甲.
package rand
/*
#include stdlib.h
*/ import "C" func Random() int { return int(C.random()) } func Seed(i int) { C.srandom(C.uint(i)) }
我们来看一下这里都有什么内容. 开始是一个包的导入语句.
rand包导入了"C"包, 但你会发现在Go的标准库里没有这个包. 那是因为C是一个"伪包", 一个为cgo引入的特殊的包名, 它是C命名空间的一个引用.
rand 包包含4个到C包的引用: 调用 C.random和C.srandom, 类型转换 C.uint(i)还有引用语句.
Random函数调用libc中的random函数, 然后回返结果. 在C中, random返回一个C类型的长整形值, cgo把它轮换为C.long. 这个值必需转换成Go的类型, 才能在Go程序中使用. 使用一个常见的Go类型转换:
func Random() int { return int(C.random()) }
这是一个等价的函数, 使用了一个临时变量来进行类型转换:
func Random() int { var r C.long = C.random() return int(r) }
Seed函数则相反. 它接受一个Go语言的int类型, 转换成C语言的unsigned int类型, 然后传递给C的srandom函数.
func Seed(i int) { C.srandom(C.uint(i)) }
需要注意的是, cgo中的unsigned int类型写为C.uint; cgo的文档中有完整的类型列表.
这个例子中还有一个细节我们没有说到, 那就是导入语句上面的注释.
/*
#include stdlib.h
*/ import "C"
Cgo可以识别这个注释, 并在编译C语言程序的时候将它当作一个头文件来处理. 在这个例子中, 它只是一个include语句, 然而其实它可以是使用有效的C语言代码. 这个注释必需紧靠在import "C"这个语句的上面, 不能有空行, 就像是文档注释一样.
Strings and things
与Go语言不同, C语言中没有显式的字符串类型. 字符串在C语言中是一个以0结尾的字符数组.
Go和C语言中的字符串转换是通过C.CString, C.GoString,和C.GoStringN这些函数进行的. 这些转换将得到字符串类型的一个副本.
下一个例子是实现一个Print函数, 它使用C标准库中的fputs函数把一个字符串写到标准输出上:
package print // #include stdio.h // #include stdlib.h import "C" import "unsafe" func Print(s string) { cs := C.CString(s) C.fputs(cs, (*C.FILE)(C.stdout)) C.free(unsafe.Pointer(cs)) }
在C程序中进行的内存分配是不能被Go语言的内存管理器感知的. 当你使用C.CString创建一个C字符串时(或者其它类型的C语言内存分配), 你必需记得在使用完后用C.free来释放它.
调用C.CString将返回一个指向字符数组开始处的指错, 所以在函数退出前我们把它转换成一个unsafe.Pointer(Go中与C的void 等价的东西), 使用C.free来释放分配的内存. 一个惯用法是在分配内存后紧跟一个defer(特别是当这段代码比较复杂的时候), 这样我们就有了下面这个Print函数:
func Print(s string) { cs := C.CString(s) defer C.free(unsafe.Pointer(cs)) C.fputs(cs, (*C.FILE)(C.stdout)) }
构建 cgo 包
如果你使用goinstall, 构建cgo包就比较容易了, 只要调用像平常一样使用goinstall命令, 它就能自动识别这个特殊的import "C", 然后自动使用cgo来编译这些文件.
如果你想使用Go的Makefiles来构建, 那在CGOFILES变量中列出那些要用cgo处理的文件, 就像GOFILES变量包含一般的Go源文件一样.
rand包的Makefile可以写成下面这样:
include $(GOROOT)/src/Make.inc
TARG=goblog/rand
CGOFILES=\ rand.go\ include $(GOROOT)/src/Make.pkg
然后输入gomake开始构建.
更多 cgo 的资源
cgo的文档中包含了关于C伪包的更多详细的说明, 以及构建过程. Go代码树中的cgo的例子给出了更多更高级的用法.
一个简单而又符合Go惯用法的基于cgo的包是Russ Cox写的gosqlite. 而Go语言的网站上也列出了更多的的cgo包.
最后, 如果你对于cgo的内部是怎么运作这个事情感到好奇的话, 去看看运行时包的cgocall.c文件的注释吧.
SQLite是ANSI-C的源代码。在使用之前必须要编译成机器码。这篇文章是用于各种编译SQLite方法的指南。
这篇文章不包含编译SQLite的每个步骤的反馈,那样可能会困难因为每种开发场景都不同。所以这篇文章描述和阐述了编译Sqlite的原则。典型的编译命令已经作为例子提供了,以期望应用开发者能够使用这些例子作为完成他们自己定制的编译过程的的一个指南。换句话说,这篇文章提供了想法和见解,而不是交钥匙的解决方法。
融合VS单独源文件
Sqlite是由超过一百个c源码文件以及众多的目录下的脚本构建的。Sqlite的实现是纯粹的ANSI-C,但是许多C语言源代码文件是由辅助的C程序生成或者转换来的,并且AWK,SED和TCL脚本会融合到完成的sqlite库中。对Sqlite构建需要的C程序和转换和创建C语言源码是一个复杂的过程。
为了简化这些,sqlite也通过一个预打包的合并后的源码文件:sqlite3.c。这个合并文件是一个ANSI-C源码实现整个SQLite库的唯一文件。合并后的文件更容易处理。所有的东西都包含在这一个文件里,所以很容易进入一个更大的C或者C++程序的源码树。所有的代码生成和转换步骤都已经实现了,因此没有辅助的C程序需要去配置和变异,也没有脚本需要去运行。并且,因此所有哭都包含在一个翻译单元,编译器可以做更多高级的优化从而提升5%到10%的性能。因为这些原因,融合后的源码文件sqlite3.c对所有程序来讲都是值得推荐的。
推荐所有的应用程序使用融合文件。
直接从单独的源码文件中构建sqlite当然可以,但是并不推荐。对一些特殊的应用程序,可能需要修改构建程序去处理使用那些从网站上下载的预构建的源码文件不能完成的情况。对于这些情况,推荐构建和使用一个定制过的合并文件。换句话说,即使一个工程需要以单独的源码文件构建sqlite,仍然推荐使用一个融合后的源码文件作为一个中间步骤。
编译命令行接口(CLI)
构建命令行接口需要三个源码文件:
sqlite3.c:Sqlite融合的源码文件
sqlite3.h:匹配sqlite3.c以及定义sqlite的c语言接口的头文件
shell.c:命令行接口程序本身。这个c源码文件包含一个main()的例程和每轮循环的用户输入的提示符并将输入传给sqlite数据库引擎用于处理。
所有的上述源码的三个文件都被包含在下载页面的amalgamation tarball中。
为了构建CLI,简单的将这三个文件放置在相同的目录下然后一起编译他们。用MSVC:
cl shell.c sqlite3.c -Fesqlite3.exe
在unix系统上(或者在windows上用cygwin或者mingw+msys)典型的命令会有些像这样:
gcc shell.c sqlite3.c -lpthread -ldl
为了SQLite线程安全,需要pthreads库。但是因为CLI是一个单线程的,我们可以指示SQLite构建一个非线程安全的库并因此护绿pthreads库:
gcc -DSQLITE_THREADSAFE=0 shell.c sqlite3.c -ldl
-ldl库是在支持动态装载时需要,例如sqlite3_load_extension() 接口和load_extension()
SQL function。如果这些特性都不要求,那么我们也可以使用SQLITE_OMIT_LOAD_EXTENSION编译时间选项忽略他们。
gcc -DSQLITE_THREADSAFE=0 -DSQLITE_OMIT_LOAD_EXTENSION shell.c sqlite3.c
有人可能想要提供其他的编译时间选项(compile-time options),例如SQLITE_ENABLE_FTS3去全文本搜索或者SQLITE_ENABLE_RTREE用于R*树搜索引擎扩展。而有人将正常指定一些编译优化开关。(预编译的CLI可以从选择sqlite网站上使用“-Os”下载下来)有无数种可能的变数在这里。
关键点在这里:构建CLI需要编译一起两个C语言文件。shell.c文件包含入口的定义和用户输入的loop,而sqlite融合文件sqlite3.c包含完整的sqlite库的实现。
编译TCL接口
sqlite的tcl接口是一个小的模块被添加到一般的融合文件中。结果是一个新的融合后的源码文件,称之为“tclsqlite3.c”。这个源码文件是生成一个可以使用TCL
load命令去加载到一个标准的tclsh或者wish中,或者随着sqlite构建成功生成一个单独唯一的tclsh的共享库所需要的。一个tcl的融合的副本被包含在下载页的TEA
tarball中作为一个文件。
为了生成一个linux上的sqlite的TCL-loadable库,下面的命令需要满足:
gcc -o libtclsqlite3.so -shared tclsqlite3.c -lpthread -ldl -ltcl
不幸的是构建Mac OS X 和 Windows的共享库并不是如此简单。对于这些平台最好使用包含在TEA tarball中的configure脚本和makefile.
为了生成一个单独的tclsh,可以用于sqlite静态链接,使用如下的编译器调用:
gcc -DTCLSH=1 tclsqlite3.c -ltcl -lpthread -ldl -lz -lm
这里的技巧是-DTCLSH=1选项。sqlite的TCL接口模块包含一个main的过程,用于初始化一个TCL解释器并在以-DTCLSH=1编译后进入到一个命令行loop。上述命令可以工作在Linux和Mac
OS X,虽然有时可能需要依赖于平台调整库选项以及编译的TCL的哪一个版本。
构建融合文件
下载页提供的sqlite融合文件的版本对大多数用户来说是足够的。然而,一些工程可能想要或者需要构建他们自己的融合文件。一个常见的构建一个定制的融合文件的理由是为了使用特定的compile-time options来定制sqlite库。回想sqlite融合文件中包含了许多C代码由辅助程序和脚本生成。许多的编译时间选项影响这一成圣代码而且必须在融合文件组装前提供给代码生成器。这一系列必须传给代码生成器的编译时间相关的选项会使得sqlite的发布版本各不相同,但是在写这边文章的时候,代码生成器需要知道的这组选项包括:
SQLITE_ENABLE_UPDATE_DELETE_LIMIT
SQLITE_OMIT_ALTERTABLE
SQLITE_OMIT_ANALYZE
SQLITE_OMIT_ATTACH
SQLITE_OMIT_AUTOINCREMENT
SQLITE_OMIT_CAST
SQLITE_OMIT_COMPOUND_SELECT
SQLITE_OMIT_EXPLAIN
SQLITE_OMIT_FOREIGN_KEY
SQLITE_OMIT_PRAGMA
SQLITE_OMIT_REINDEX
SQLITE_OMIT_SUBQUERY
SQLITE_OMIT_TEMPDB
SQLITE_OMIT_TRIGGER
SQLITE_OMIT_VACUUM
SQLITE_OMIT_VIEW
SQLITE_OMIT_VIRTUALTABLE
为了构建一个定制的融合文件,先下载原始的独立源码文件到一个unix或者类unix开发平台。确定获取的原始源码文件不是“预编译过的源文件”。任何人都可以通过到下载页或者直接从configuration management system.获取完整的一套原始源码文件。
假设sqlite源码树被存在一个名为“sqlite”的目录下。计划构建一个平行目录下的名为“bld”的融合文件。首先通过运行sqlite源码树种的configure脚本运行或者通过制作一份源码树顶层的的makfile模板的一份,来构建一个合适的makefile.然后手动编辑这个Makfile去包含需要的编译时间相关的选项。最终运行:
make sqlite3.c
在windows上使用MSVC:
nmake /f Makefile.msc sqlite3.c
sqlite3.c的make
target会自动构造一般的“sqlite3.c”合并的源码文件,以及它的头文件“sqlite3.h”,和包含TCL接口的融合源码文件“tclsqlite3.c”。之后,需要的文件可以被拷贝到文件目录下然后根据上述勾勒的过程编译。
构建一个windows的动态链接库DLL
为了在windows构建一个sqlite的dll使用,首先获取对应的融合过的源码文件,sqlit3.c和sqlite.h。这些可以从SQLite website上下载或者和上述告知的一样去定制生成。
使用工作目录下的源码文件,一个dll可以在msvc中使用如下命令生成:
cl sqlite3.c -link -dll -out:sqlite3.dll
上述命令需要运行在msvc的MSVC Native Tools Command
Prompt.如何你已经在机器上安装了msvc,你可能有多个版本的这种命令提示符,针对于x86和x64的自带构建的,或者交叉编译到ARM的。依赖要求的DLL去使用对应合适的命令提示符工具。
如果使用MinGW编译器,命令是这样的:
gcc -shared sqlite3.c -o sqlite3.dll
注意MinGW只生成32位的dll。另有一个分开的MinGW64工程可以用来生成64位的dll。可以推断其命令行语法是类似的。需要注意的是最近的MSVC的版本生成的DLLs可能不能工作到WinXP或者更早版本的windows上。因此为了最大限度的兼容你的生成的dll,推荐MinGW。一个好的经验法则是使用MinGW去生成32位的dlls,使用msvc去生成64位的dlls。
go/src/go-cve-dictionary-master
# mv subcommands-master /opt/go/src/subcommands
# mv net-master /opt/go/src/net
# mv go-sqlite3-master /opt/go/src/go-sqlite3
都放到了go/src目录下了,我还修改了go-cve-dictionary-master/main.go文件内容,如下所示:
import (
"flag"
"fmt"
"os"
"golang.org/x/net/context" 改为 “context”
"github.com/google/subcommands" 改为 subcommands
"github.com/kotakanbe/go-cve-dictionary/commands" 改为 go-cve-dictionary/commands
"github.com/kotakanbe/go-cve-dictionary/version" 改为 go-cve-dictionary/version
_ "github.com/mattn/go-sqlite3" 改为 go-sqlite3
)
执行 # go install go-cve-dictionary-master 错误如下:
can't load package: /opt/go/src/go-cve-dictionary-master/main.go:14:2: non-standard import "github.com/mattn/go-sqlite3" in standard package "go-cve-dictionary-master"
go-cve-dictionary-master/main.go:11:2: cannot find package "go-cve-dictionary/commands" in any of:
/opt/go/src/vendor/go-cve-dictionary/commands (vendor tree)
/opt/go/src/go-cve-dictionary/commands (from $GOROOT)
/root/go/src/go-cve-dictionary/commands (from $GOPATH)
go-cve-dictionary-master/main.go:12:2: cannot find package "go-cve-dictionary/version" in any of:
/opt/go/src/vendor/go-cve-dictionary/version (vendor tree)
/opt/go/src/go-cve-dictionary/version (from $GOROOT)
/root/go/src/go-cve-dictionary/version (from $GOPATH)
subcommands/subcommands.go:29:2: cannot find package "golang.org/x/net/context" in any of:
/opt/go/src/vendor/golang.org/x/net/context (vendor tree)
/opt/go/src/golang.org/x/net/context (from $GOROOT)
/root/go/src/golang.org/x/net/context (from $GOPATH
SQLite数据库通常存储在单个普通磁盘文件中。但是,在某些情况下,数据库可能存储在内存中。
强制SQLite数据库单纯的存在于内存中的最常用方法是使用特殊文件名“ :memory: ” 打开数据库。换句话说,不是将真实磁盘文件的名称传递给sqlite3_open(),sqlite3_open16()或 sqlite3_open_v2()函数之一,而是传入字符串“:memory:”。例如:
调用此接口完成后,不会打开任何磁盘文件。而是在内存中创建一个新的数据库。数据库连接关闭后,数据库就不再存在。每一个memory数据库彼此不同。因此,打开两个数据库连接,每个数据库连接的文件名为“:memory:”,将创建两个独立的内存数据库。
特殊文件名“:memory:”可用于允许数据库文件名的任何位置。例如,它可以被用作 文件名 中的ATTACH命令:
请注意,为了应用特殊的“:memory:”名称并创建纯内存数据库,文件名中不能有其他文本。因此,可以通过添加路径名在文件中创建基于磁盘的数据库,如下所示: "./:memory:"。
使用URI文件名时,特殊的“:memory:”文件名也可以使用。例如:
要么,
如果使用URI文件名打开内存数据库,则允许它们使用共享缓存。如果使用未加修饰的“:memory:”名称来指定内存数据库,那么该数据库始终具有专用高速缓存,并且仅对最初打开它的数据库连接可见。但是,可以通过两个或多个数据库连接打开相同的内存数据库,如下所示:
要么,
这允许单独的数据库连接共享相同的内存数据库。当然,共享内存数据库的所有数据库连接都需要在同一个进程中。当数据库的最后一个连接关闭时,将自动删除数据库并回收内存。
如果在单个进程中需要两个或多个不同同时可共享的内存数据库,则mode = memory查询参数可与URI文件名一起使用以创建命名的内存数据库:
要么,
当以这种方式命名内存数据库时,它将仅与使用完全相同名称的另一个连接共享其缓存。
当传递给sqlite3_open()或 ATTACH的数据库文件的名称是空字符串时,则会创建一个新的临时文件来保存数据库。
每次都会创建一个不同的临时文件,因此就像使用特殊的“:memory:”字符串一样,两个到临时数据库的数据库连接都有自己的私有数据库。创建它们的连接关闭时,将自动删除临时数据库。
即使为每个临时数据库分配了磁盘文件,实际上临时数据库通常驻留在内存中的pager缓存中,因此“:memory:”创建的纯内存数据库与临时数据库之间的差别很小。由空文件名创建。唯一的区别是“:memory:”数据库必须始终保留在内存中,而如果数据库变大或SQLite受到内存压力,临时数据库的某些部分可能会刷新到磁盘。
前面的段落描述了默认SQLite配置下临时数据库的行为。如果需要,应用程序可以使用 temp_store编译指示和SQLITE_TEMP_STORE编译时参数来强制临时数据库表现为纯内存数据库。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流