📄 metakit quick and easy storage for your tcl application.mht
字号:
From: =?Windows-1252?B?08kgV2luZG93cyBJbnRlcm5ldCBFeHBsb3JlciA3ILGjtOY=?=
Subject: MetaKit: Quick and Easy Storage for your Tcl Application
Date: Fri, 29 Feb 2008 00:30:58 +0800
MIME-Version: 1.0
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Content-Location: http://www.markroseman.com/tcl/mktcl.html
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>MetaKit: Quick and Easy Storage for your Tcl =
Application</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3D"MSHTML 6.00.6000.16609" name=3DGENERATOR></HEAD>
<BODY>
<H1>MetaKit: Quick and Easy Storage for your Tcl Application</H1>Author: =
Mark=20
Roseman (mark at markroseman.com) <BR>HTML Demangler: Mars Di Bona =
(MarsDiBona=20
at fiberia.com) <BR><!-- Created: Wed Apr 03 14:28:30 EST 2002 --><!-- =
hhmts start -->Last=20
modified: Wed Apr 03 17:25:43 Eastern Standard Time 2002 <!-- hhmts end =
-->
<P>Ever needed a simple and powerful way to store and retrieve data in =
your=20
latest Tcl masterpiece? </P>
<P>Finding yourself cursing at the explosion of small data files =
littering your=20
disk as your application grew? </P>
<P>Would you like to get a handle on efficiently extracting the right =
results=20
from your data, without having to digest a 5-pound book on SQL to do it? =
</P>
<P>Need storage that won't require a painful database installation, a =
dedicated=20
database analyst to maintain it, and all the associated Tcl extensions =
needed to=20
get it to work with your code? </P>
<P>If you're like most developers, you probably would have answered =
"YES!!!" to=20
these questions on several different occasions. If so, you could =
probably=20
benefit from MetaKit, a storage engine that's ideally matched to Tcl: =
dynamic,=20
flexible, easy to learn, embeddable, and very powerful. </P>
<P>In this document, we'll explore how you can use MetaKit to solve the =
data=20
storage needs of your Tcl applications. You'll find out what makes =
MetaKit=20
different than other approaches, and whether it's the right approach for =
you.=20
You'll see how to use MetaKit from within your own Tcl programs, and =
learn the=20
small number of MetaKit commands that you'll need to use for most =
applications.=20
</P>
<P>In no time, you'll be proficient enough that you'll never (well, ok, =
hardly=20
ever) look at a flat file storage solution again. So lets start by =
taking a=20
closer look at what MetaKit provides you with. </P>
<H2>What is MetaKit?</H2>
<P>MetaKit is a freely available, cross platform, open source (MIT-style =
licensed) database library that you can include in your own programs. It =
has=20
been developed by Jean-Claude Wippler, the man behind Equi4 Software=20
(www.equi4.com). MetaKit comes with an API for C++, one for Python, and =
the one=20
we're most interested in here, an API for Tcl called "Mk4tcl". </P>
<P>Like every other database or storage library, MetaKit helps you =
manage the=20
data you want to store on disk. However, it does things somewhat =
differently=20
from many other database libraries, which give it a number of unique =
advantages,=20
some of which are ideally paired to scripting languages like Tcl. We'll =
explore=20
some of these differences here. </P>
<H3>A First Example</H3>
<P>But first, lets look at a quick example to give you a feel for what a =
Tcl=20
program using MetaKit might look like. This admittedly contrived example =
shows=20
how you can store information into a data file and then easily search =
for=20
particular pieces of that information. If you already have MetaKit =
installed on=20
your system (which is done exactly like any other Tcl package), you can =
actually=20
try this one out right now. If not, we'll provide details at the end of =
this=20
document on how to obtain and install MetaKit. </P><PRE># load MetaKit =
into our application; Mk4tcl is the name of the Tcl extension
package require Mk4tcl
# open a datafile named mydata.db; we'll refer to it with the tag 'db'
mk::file open db mydata.db
# create a view within the datafile which describes what we'll store
set view [mk::view layout db.addressbook "name country"]
# create a bunch of new rows in the view to store our data
mk::row append $view name "Mark Roseman" country "Canada"
mk::row append $view name "Jean-Claude Wippler" country "The =
Netherlands"
mk::row append $view name "Jeff Hobbs" country "Canada"
mk::file commit $view
# search for all living in Canada and print their names
foreach row [mk::select $view country "Canada"] {
puts [mk::get $view!$row name]
}
# close the datafile
mk::file close db</PRE>
<P>So in a few lines of not-very-complex code, we can open a database =
(creating=20
it if needed), say what we want to store in it (which may even be =
slightly=20
different than the last time we opened it; MetaKit will adjust as =
needed), write=20
some data, and do a simple search. That's all that's needed; we didn't =
need to=20
install or set up a special database daemon somewhere on our system, =
etc.=20
Everything that's needed is right in the MetaKit Tcl extension itself. =
</P>
<H3>Easy to Learn</H3>
<P>As the simple program above suggests, one of MetaKit's strong points =
is that=20
it's very easy to learn. While a bit of familiarity with "standard" =
database=20
concepts will go a long way, you certainly don't need to be an expert to =
be=20
proficient with MetaKit. In particular, you certainly don't need to =
learn the=20
nuances of complex query languages such as SQL. As with many things in =
Tcl, the=20
level of abstraction is kept high enough so that your projects don't =
need a=20
large team, where each member is proficient in a single area. Instead, a =
single=20
person can handle multiple areas of the program, and with MetaKit, that =
includes=20
data storage. </P>
<P>MetaKit's API relies on concepts familiar to programmers, where data =
is=20
accessed by indexing into a set of rows, each row containing a number of =
named=20
properties. By relying on a straightforward and very concrete model, =
programmers=20
don't get hung up learning more abstract concepts right at the start. =
</P>
<H3>Scriptable and Dynamic</H3>
<P>Part of what contributes to MetaKit's ease of learning and ease of =
use is how=20
naturally it fits into the scripting language paradigm. It's very =
natural to=20
open up a Tcl shell and start typing in MetaKit commands. Everything is =
open to=20
very easy inspection, such as the structure of your data file, all the =
data=20
contained in it, "cursors" showing you your position as you iterate =
through rows=20
in the file, and so on. </P>
<P>MetaKit's not only lets you inspect data files, but even change their =
structure on the fly. If in your application, you decide to add a new =
field to=20
the database, you can simply add the new field to the "view" and the =
data file=20
will automatically be adjusted. Unlike with a lot of databases, this =
gives you a=20
lot of flexibility even in the early prototype stages of your =
application. </P>
<H3>Easily Embedded and Deployed</H3>
<P>One of MetaKit's exceptional advantages is how easily your =
applications and=20
databases can be deployed. We've already touched on the fact that it =
doesn't=20
require a separate database application to be installed on your system, =
but just=20
the MetaKit library, linked in or dynamically loaded into your =
application. The=20
library itself is quite small, only several hundred kilobytes in size. =
</P>
<P>The data files you store are themselves self-contained, i.e. you =
needn't have=20
to worry about multiple files containing your database. For those of you =
deploying applications that run on multiple platforms, MetaKit data =
files have=20
the additional advantage of being easily moved between platforms, with =
no=20
conversions required. And MetaKit is available for a variety of =
platforms,=20
including Windows, Mac, Linux, Solaris and a variety of other Unix =
systems. </P>
<H3>Reliable and Efficient</H3>
<P>A critical requirement of any database or storage library, MetaKit =
goes to=20
great pains to ensure that your data is always safely stored. Your data =
files=20
will not become corrupted. </P>
<P>MetaKit is also very efficient. By using internal implementation =
techniques=20
like "column-wise storage" and memory mapped files (both of which map =
nicely=20
onto the API), data access and manipulation is almost always extremely =
fast.=20
</P>
<H3>What MetaKit is Not</H3>
<P>Of course, given some of these advantages, there are tradeoffs. There =
are=20
some things that MetaKit does not provide, that may or may not be =
important to=20
your particular application. </P>
<P><I>SQL</I>. MetaKit has its own API, and does not conform to the SQL =
API used=20
by many higher end database products. If you are migrating code from an =
existing=20
SQL database, or require that you be able to migrate to a SQL database, =
MetaKit=20
may not be the right choice for you. That being said, SQL =
implementations vary=20
considerably between products regardless, so any migration is bound to =
involve=20
some effort. Similarly, if you require extremely complex queries or=20
sophisticated data constraints, which SQL was designed to deal with, =
MetaKit may=20
not be a good fit. </P>
<P><I>Concurrent</I>. Only a single process (or thread) at a time can =
access a=20
MetaKit data file, unlike many other products that allow multiple =
processes or=20
threads to access the database at once. This is common in web servers =
for=20
example, where different CGI processes will share access to the same =
database.=20
Underneath of course, the database itself mediates access to the data. =
With=20
MetaKit, your application would have to mediate access. A common =
architecture=20
for addressing this problem is to have a single server process that =
accesses the=20
database, with clients (such as the CGI processes in this example) =
making=20
database requests of this server. We won't cover this here. </P>
<P><I>Massively Scalable</I>. MetaKit will comfortably handle data files =
up to=20
several hundred megabytes, and with a few tricks, you can push things a =
fair bit=20
further. However, if you're looking to store data files of several =
gigabytes or=20
more, you will probably need to look to alternative solutions. </P>
<H2>MetaKit Concepts</H2>
<P>There are only a few concepts that you'll need to know to use =
MetaKit. Most=20
of these should be familiar to you if you've used any other database or =
storage=20
mechanism, though perhaps under a different name. </P>
<P><I>Datafile</I>. MetaKit stores all its data in one or more =
self-contained=20
data files on disk. These live like any other file in the file system; =
you open=20
them with MetaKit when you want to access your data, and you close them=20
afterwards. When you open a file, you specify a 'tag' that is associated =
with=20
the open file (e.g. "db" in the earlier example). You can have multiple =
data=20
files open at once, where each would have a different tag. </P>
<P><I>View</I>. Views let you partition your data files into one or more =
separate areas, each of which may hold different types of data. The =
description=20
of what data each view can hold is referred to as its layout, or =
structure.=20
Views are specified as tag.viewname (e.g. "db.addressbook" earlier). =
Views are=20
equivalent to 'tables' in many other databases. </P>
<P><I>Row</I>. A row holds a collection of data related to the same =
object, such=20
as the name, address, etc. of a person in an address book. This is =
commonly=20
referred to as a 'record' in many other databases. A view is actually =
made up of=20
an array of rows, which are referred to by a zero-based index (i.e. the =
first=20
row is '0', the second is '1', etc.). You can refer to an individual row =
within=20
a view by tag.viewname!index (e.g. "db.addressbook!3"). </P>
<P><I>Properties</I>. A property is an individual data item. Each row =
will hold=20
one or more properties. Each row within a single view will contain the =
same=20
properties, though of course they will likely have different values. So =
for=20
example, every row within the view may have a name and address property, =
but the=20
values will be different for each row. Rows are commonly known as =
'fields' in=20
many other databases. Note that properties are not referred to directly =
by a=20
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -