Hi,
I have a method to save employees and company information to a file
using these methods:
(defmethod make-load-form ((self company) &optional environment)
...)
(defmethod make-load-form ((self employee) &optional environment)
...)
(defmethod save-all ((c company) file)
(compile-file
(with-open-file (s file :direction :output :if-exists :supersede)
(format s "(in-package \"EMPLOYEE\")~
(setf *company* '#.*company*)~%")
file)))
To reload the database, I just need to (load file).
My database is not big but I am not confortable with the fact that
everytime I update an employee information, I have to save all the
objects again.
Is there a way to save only updated information?
Thanks.
······@dtpq.com (Christopher C. Stacy) wrote in message news:<·············@dtpq.com>...
> CLOS is not a database.
We both know that.
From: Christopher C. Stacy
Subject: Re: Updating a database of object with CLOS
Date:
Message-ID: <uk7j62xja.fsf@dtpq.com>
>>>>> On 21 Nov 2002 15:32:43 -0800, Delaregue ("Delaregue") writes:
Delaregue> ······@dtpq.com (Christopher C. Stacy) wrote in message news:<·············@dtpq.com>...
>> CLOS is not a database.
Delaregue> We both know that.
Well, then you already know the answer: if you want persistent
storage of the data in your CLOS instances, you're going to
have to develop some kind of database (or acquire one).
Checking Google, you would learn:
Franz has something you can use.
Not sure if Xanalys does.
Another one is PLOB.
······@dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 21 Nov 2002 15:32:43 -0800, Delaregue ("Delaregue") writes:
>
> Delaregue> ······@dtpq.com (Christopher C. Stacy) wrote in message news:<·············@dtpq.com>...
> >> CLOS is not a database.
> Delaregue> We both know that.
>
> Well, then you already know the answer: if you want persistent
> storage of the data in your CLOS instances, you're going to
> have to develop some kind of database (or acquire one).
>
> Checking Google, you would learn:
> Franz has something you can use.
> Not sure if Xanalys does.
> Another one is PLOB.
On Unix-like platforms, dbm/ndbm/db[1234]/gdbm may be
useful. That will require some FFI code, as well as some sort of
serialisation/deserialisation scheme for the classes you want to
store.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
From: Erik Naggum
Subject: Re: Updating a database of object with CLOS
Date:
Message-ID: <3246923440767292@naggum.no>
* ·········@netscape.net (Delaregue)
| Is there a way to save only updated information?
How about only saving changes by appending to the file? This will in
effect be a transaction log and you can even achieve real transactions by
saving `begin� and `commit� forms so you can save changes made in each
update method and then finalize them. Every once in a while, do a full
save of the database. All of this may be accomplished with a meta-class.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> wrote in message news:<················@naggum.no>...
> How about only saving changes by appending to the file? This will in
I like the idea. I will investigate it since I have now a better
understanding of how serialisation with CLOS works. The variety of
concepts involved with serialisation has somehow made me blind to what
seems to be a simple solution!
Thanks.
From: Tim Bradshaw
Subject: Re: Updating a database of object with CLOS
Date:
Message-ID: <ey3vg2pahuw.fsf@cley.com>
* Erik Naggum wrote:
> How about only saving changes by appending to the file? This will in
> effect be a transaction log and you can even achieve real transactions by
> saving `begin� and `commit� forms so you can save changes made in each
> update method and then finalize them. Every once in a while, do a full
> save of the database. All of this may be accomplished with a meta-class.
I played with a system that did more-or-less this - dribbling changes
to a transaction file, and then reloading the original file + dribble
file on startup. Every once in a while you need to do a resync to
stop the dribble file becoming too huge (and thus startup taking a
very very long time). I don't have code any more (never got anywhere
near finished...)
I also worked on a commercial system which did mostly this - it had
once used Oracle but they'd moved to keeping transaction logs in a
file. This worked OK too, though there were problems of corruption
(due to general cruftiness, not the technique).
--tim
Delaregue wrote:
> My database is not big but I am not confortable with the fact that
> everytime I update an employee information, I have to save all the
> objects again.
> Is there a way to save only updated information?
Just a simple-minded thought, but seeing as how the PostgreSQL
data directory seems to have a gazillion files (even if you have
only a few tables defined or even no tables), how about...
- one file per object
- or one file per cluster of objects
On an update, you would arrange to save only that object or cluster,
disconnecting it (and saving the info needed for later reconnection)
if necessary.
On a load, you would arrange to reconnect each object or
cluster with the rest of the world.
My vague impression is that one of the available database interfaces
(UncommonSQL) allows you to have CLOS objects be stored in
a database. If so, I suppose that gives us persistent CLOS, right?