Home > Archive > Tcl > June 2006 > writable metakit file inside a starkit
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
writable metakit file inside a starkit
|
|
| adam.short@gmail.com 2006-06-28, 10:01 pm |
| Is this just a fevered daydream I ought to forget, or is there a way to
open a metakit database from inside the executing starkit, write to it
and close it again? I'm writing an application and I'd really like to
extend the single file install philosophy to my data too. I realise
that the application would grow and shrink depending on the size of the
database and I'm comfortable with that, I just need to know how to make
it work.
There is an incantation on the metakit manpage that is supposed to open
a file and an in-memory database and load the latter with the former,
but it doesn't seem to work. I get file load errors.
Has anyone done this?
On another note, if I ever decide to make the starkit a starpack, will
it still work?
| |
| Michael Schlenker 2006-06-28, 10:01 pm |
| adam.short@gmail.com schrieb:
> Is this just a fevered daydream I ought to forget, or is there a way to
> open a metakit database from inside the executing starkit, write to it
> and close it again? I'm writing an application and I'd really like to
> extend the single file install philosophy to my data too. I realise
> that the application would grow and shrink depending on the size of the
> database and I'm comfortable with that, I just need to know how to make
> it work.
There are ways to do it. As a starkit is just a metakit database you
should be able to open it as a normal metakit database, with just some
special views which hold the filesystem.
Try this:
package require Mk4tcl
mk::file open db $::starkit::topdir
# show the existing filesystem
puts "VIEWS:"
puts [mk::file views db]
puts "Layout for dirs"
puts [mk::view layout db.dirs]
# create a new view
mk::view layout db.metadata {user:s info:s}
mk::row append db.metadata user Joe info "Hello World"
mk::file commit db
mk::file close db
put it in a file, then use sdx qwrap to turn it in a starkit and see
what it does.
>
> There is an incantation on the metakit manpage that is supposed to open
> a file and an in-memory database and load the latter with the former,
> but it doesn't seem to work. I get file load errors.
>
> Has anyone done this?
>
> On another note, if I ever decide to make the starkit a starpack, will
> it still work?
Not on all platforms. Windows does not allow it to write to a running
executable. Others may have similar issues.
Michael
| |
| adam.short@gmail.com 2006-06-28, 10:01 pm |
|
Michael Schlenker wrote:
> Try this:
> package require Mk4tcl
> mk::file open db $::starkit::topdir
>
> # show the existing filesystem
> puts "VIEWS:"
> puts [mk::file views db]
> puts "Layout for dirs"
> puts [mk::view layout db.dirs]
>
> # create a new view
> mk::view layout db.metadata {user:s info:s}
> mk::row append db.metadata user Joe info "Hello World"
> mk::file commit db
> mk::file close db
Hmmm... that's a totally different way of doing it than what I'd
considered so far, but I see no reason why it wouldn't work. In fact,
it's actually neater than what I was doing (I was actually attempting
to write to a file inside the starkit, I never thought of treating the
starkit itself as a metakit database).
Cheers, I'll try it.
| |
| adam.short@gmail.com 2006-06-28, 10:01 pm |
|
Michael Schlenker wrote:
> Try this:
> package require Mk4tcl
> mk::file open db $::starkit::topdir
>
> # show the existing filesystem
> puts "VIEWS:"
> puts [mk::file views db]
> puts "Layout for dirs"
> puts [mk::view layout db.dirs]
>
> # create a new view
> mk::view layout db.metadata {user:s info:s}
> mk::row append db.metadata user Joe info "Hello World"
> mk::file commit db
> mk::file close db
Sadly this doesn't seem to do what I want. It seems to act on an
in-memory copy of the starkit/metakit, and doesn't seem to touch the
filesystem. The data goes in fine, and I can read it back while the app
is still running, but if I close it down and start it up again, the
data is gone. If I want it to persist across several sessions,
something has to be written to disk somewhere. Nifty trick for storing
data while the app is running though.
| |
| Michael Schlenker 2006-06-28, 10:01 pm |
| adam.short@gmail.com schrieb:
> Michael Schlenker wrote:
>
>
> Sadly this doesn't seem to do what I want. It seems to act on an
> in-memory copy of the starkit/metakit, and doesn't seem to touch the
> filesystem. The data goes in fine, and I can read it back while the app
> is still running, but if I close it down and start it up again, the
> data is gone. If I want it to persist across several sessions,
> something has to be written to disk somewhere. Nifty trick for storing
> data while the app is running though.
>
Strange. It works for me..., with this script:
package require Mk4tcl
mk::file open db $::starkit::topdir
# show the existing filesystem
puts "VIEWS:"
puts [mk::file views db]
puts "Layout for dirs"
puts [mk::view layout db.dirs]
# create a new view
mk::view layout db.metadata {user:s info:s}
mk::row append db.metadata user Joe info "Hello World"
mk::loop i db.metadata {
puts [mk::get $i]
}
mk::file commit db
mk::file close db
each call of the starkit adds one row to the loop, but not every call
increases the filesize..., run a few dozend times to see an increase of
the file size.
(this is on SUSE Linux 10.1 x86_64...)
Michael
| |
| adam.short@gmail.com 2006-06-29, 4:03 am |
|
Michael Schlenker wrote:
> Strange. It works for me..., with this script:
>
> package require Mk4tcl
> mk::file open db $::starkit::topdir
>
> # show the existing filesystem
> puts "VIEWS:"
> puts [mk::file views db]
> puts "Layout for dirs"
> puts [mk::view layout db.dirs]
>
> # create a new view
> mk::view layout db.metadata {user:s info:s}
> mk::row append db.metadata user Joe info "Hello World"
> mk::loop i db.metadata {
> puts [mk::get $i]
> }
> mk::file commit db
> mk::file close db
>
> each call of the starkit adds one row to the loop, but not every call
> increases the filesize..., run a few dozend times to see an increase of
> the file size.
Yes, oddly, your script does exactly as you describe. Mine is
essentially doing the same thing, but it loses the new view each time.
I put a "puts [mk::file views db]" in there and the extra view isn't
there on the second and subsequent runs. I'll check it again tonight,
as it seems like the principle should work fine, though I can't see
what I'm doing wrong. It shouldn't be possible to get rid of a view
without explicitly removing it, should it? I'm  now.
| |
| Michael Schlenker 2006-06-29, 8:01 am |
| adam.short@gmail.com schrieb:
> Michael Schlenker wrote:
>
>
> Yes, oddly, your script does exactly as you describe. Mine is
> essentially doing the same thing, but it loses the new view each time.
> I put a "puts [mk::file views db]" in there and the extra view isn't
> there on the second and subsequent runs. I'll check it again tonight,
> as it seems like the principle should work fine, though I can't see
> what I'm doing wrong. It shouldn't be possible to get rid of a view
> without explicitly removing it, should it? I'm now.
>
I'm not sure if a view is created on disk if it contains zero rows. So
try adding a dummy row and see if it helps.
Michael
| |
| Cameron Laird 2006-06-29, 7:04 pm |
| In article <4gggkdF1mm04mU1@news.dfncis.de>,
Michael Schlenker <schlenk@uni-oldenburg.de> wrote:
| |
| Michael Schlenker 2006-06-30, 4:01 am |
| adam.short@gmail.com schrieb:
> Michael Schlenker wrote:
>
>
> I've fixed it. The solution was counter-intuitive to say the least.
> When I was wrapping the starkit I used the -writable switch. With this
> switch, changes *don't* get written to the file using the method above.
> As soon as I tried it without that switch it worked perfectly.
>
> Thanks, Michael, for all your help, I'm really grateful. If anyone can
> explain to me why the writable switch seems to have the opposite
> behaviour to what would make sense I'd appreciate that too.
>
Ok, i think i know whats going on, but couldn't find the details how to
do it right.
1. The starkit is mounted, as it is writeable a normal mk::file open happens
2. You open the starkit database file a second time, also with mk::file
open, but metakit only supports one writer...
3. things don't work as expected
There is a way around it, i think a saw it on the starkit mailing list
(look in the mailing list archives or ask there), basically remounting
the starkit to get a database handle instead of opening it twice.
Michael
| |
| Eckhard Lehmann 2006-06-30, 4:02 am |
|
Cameron Laird wrote:
> Care is necessary in this area, indeed. It occurs to me that
> there are possibilities of confusing starpacks and starkits,
> as well as Windows vs. Linux. Under Windows, it's simply not
> possible to update starpack-embedded metakit databases by the
> method of this thread (although there are, of course, work-
> arounds). The other three combinations--Linux-starpack,
> Linux-starkit, Windows-starkit--*do* allow updates. Or at
> least they did the last time I was actively working with such.
That is exactly what I expected. I was trying to write files inside a
running starkit - in fact edit the tcl files of the application while
it was running. On Linux it kindof worked, but on windows the whole kit
was always getting corrupted.
I wouldn't recommend the way of modifying a running starkit for
production systems. There is always some space in env(HOME) or
env(APPDATA) for a metakit database with the application's preferences
or similar data.
Eckhard
| |
| Eckhard Lehmann 2006-06-30, 4:02 am |
|
Eckhard Lehmann wrote:
> That is exactly what I expected.
Ugh - I meant *experienced*, not expected... sorry
| |
| adam.short@gmail.com 2006-06-30, 4:02 am |
|
Michael Schlenker wrote:
> Ok, i think i know whats going on, but couldn't find the details how to
> do it right.
>
> 1. The starkit is mounted, as it is writeable a normal mk::file open happens
> 2. You open the starkit database file a second time, also with mk::file
> open, but metakit only supports one writer...
> 3. things don't work as expected
>
> There is a way around it, i think a saw it on the starkit mailing list
> (look in the mailing list archives or ask there), basically remounting
> the starkit to get a database handle instead of opening it twice.
For the time being, the solution you gave above works fine. I presume
that since the starkit isn't marked as writable, the mk::file open
doesn't happen when the starkit starts up, so my mk::file open *does*
work and writes data to the file without further hassle. Curious
arrangement, but it does seem to work great here now.
|
|
|
|
|