I'm a C++ interface user, so all my answers are in C++.

> > Q: How to delete an entire view (the opposite of: 
> storage.getas(...))?
> 
> Not sure if there's an easier way. You can create a 2nd
> storage with the views you want and use slice assignment
> to copy the data you want: v1[:] = v2.

The easiest way is to do a GetAs on the view without specifying any
properties, e.g.

        c4_Storage storage("mystore.db",true);
        storage.GetAs("view");
        storage.Commit();

> > Q: How to delete an entire column (how to transform
> >     "view[c1:S,c2:S]" to "view[c1:S]" persistently and
> >     freeing column c2)?

Same thing really ... Just get the new view without the extra property
and commit it to storage.  That should free the column.

        c4_Storage storage("mystore.db",true);
        storage.GetAs("view[c1:S]");
        storage.Commit();

Property c2 will then be gone.

> > Q: How to shrink a database? (I read making a copy might do the
> >     job. But is there a generic way to make a copy of an
> >     arbitrary data structure)?
> 
> storage.save(). A non-read-only database will generally be 2x the 
> size of the data, so shrinking it is not likely to be very useful - it
> will just double on the next modification. (There are 
> situations where 
> it's a useful trick, but they're pretty esoteric.)

The size of the db will depend heavily on how much you put in and
delete, so shrinking in many applications is necessary.  Here's the code
to do it --

        FILE *tf;
        if ((tf = fopen("mystore.db","rb")) != NULL) {
                fclose(tf);
                CFileStream fs1(fopen("~mystore.db", "wb"), true);
                c4_Storage st("mystore.db", 0);
                st.SaveTo(fs1);
                // now ~mystore.db has the compressed copy of
mystore.db.  
                CopyFile("~mystore.db","mystore.db",true);
                DeleteFile("~mystore.db");
        }

Apologies for the Win32 calls for copying and deleting, but I think
you'll get the idea.

> 
> > Q: How do I know what views are persistent and which
> >     views are transient (blocked, hash, ordered seem
> >     persistent, sort, select, union etc. seem transient...)?
> 
> What's persistent is what storage.description() tells you.
> There are no view-returning methods that do in-place mutations.
> Even with the mapping views (where MK will do the
> maintenance for you), you need to inform MK that you
> expect this on each open. (In other words, if I have an 
> ordered view, and I open it and don't use 
>  v = v.ordered(1)
> and then do an append, it will likely destroy the ordering.)
>  
> Basically, there's no metadata except what
> storage.description() tells you.

In my experience, I assume that any derived view (beyond the one I get
from GetAs()) is transient and will not allow me to do updates.  I
always use GetIndexOf() to get the index of a row in the derived view as
a row in the base view (the one from GetAs()) and do my manipulations in
the base view.

> > Q: Can I make derived views (like union, or sort) persistent?
> 
> v[:] = v.sort() is perfectly valid. If you're sorting on leftmost
> properties, you can subsequently use v.ordered().
> 
> You could similarly save a union, but you'd have to 
> define a persistent view with the right properties.
> 
> Note that derived views are generally iterators - they
> don't do much until you access them. So
>  v[:] = v.sort()
> is very expensive since it forces an in-memory
> copy of v.

Sorry, haven't tried this.
>  
> > Q: It is said that metakit uses memory mapped files. When I
> >     create a new database, the file size remains 0 (on window)
> >     until I commit. Is this a problem of windows, or is the view
> >     in memory until (the first) commit?
> 
> The latter.

Good luck.  I've been using MetaKit extensively in an app that I've
developed and I'm pretty pleased with everything except concurrent
access by multiple threads.  To get around the concurrency problems, I
open the database and then provide getStore() and releaseStore()
functions, which essentially enter and leave a critical section
(critsec) to prevent concurrent access.  In my application, database
access isn't a time critical thing, so this is really no trouble and
ensures that I don't screw up the database.

jeffrey kay 
weblog <k2.com> pgp key <www.k2.com/keys.htm> aim <jkayk2>
share files with me -- get shinkuro -- <www.shinkuro.com>

"first get your facts, then you can distort them at your leisure" --
mark twain 
"if the person in the next lane at the stoplight rolls up the window and
locks the door, support their view of life by snarling at them" -- a
biker's guide to life
"if A equals success, then the formula is A equals X plus Y plus Z. X is
work. Y is play. Z is keep your mouth shut." -- albert einstein

_______________________________________________
metakit mailing list  -  [EMAIL PROTECTED]
http://www.equi4.com/mailman/listinfo/metakit

Reply via email to