[rucksack-devel] Enhancements to Rucksack

[Jochen Schmidt]

Without having the source at hand - it wasn't much work. I've reader- and writer-transactions. You decide what you need when doing with-transaction.  Trying to write within a reader transaction restarts it as a writer transaction though. Readers can be parallel and writers are serialized.

I remember also, that I had to change conflict handling, because instances got modified before the conflict is recognized.

I changed how instances are initialized when read (activated) from disk so that transient slots can get initialized (think "sockets", "database connections" a.s.o.).

I also tried to split class definition from schema updates, so that one can define rucksack classes without an active database.

Currently I investigate how to implement a peristent (functional) B-Tree (like in couchdb).

--
Jochen Schmidt

Am 13.02.2011 um 16:18 schrieb John Pallister <john at synchromesh.com>:

> Hi Jochen,
> 
> I completely understand. If you could post a few notes to the list
> about the approach you've taken, that would be great also. I'm curious
> about how you've done this, and how much modification to the Rucksack
> internals is required... which is about as close as I've ever come to
> being interested in anything to do with the internal workings of a
> database or persistent store. ;)
> 
> Cheers,
> 
> John :^P
> 
> On Sun, Feb 13, 2011 at 2:48 PM, Jochen Schmidt <js at crispylogics.com> wrote:
>> Hello John,
>> 
>> I definitely want to publish the modifications - I just was sidetracked by some urgent customer projects. I'll look into it and put a Git repository for others to access on some server.
>> 
>> ciao,
>> Jochen
>> 
>> --
>> Jochen Schmidt
>> 
>> Am 13.02.2011 um 14:13 schrieb John Pallister <john at synchromesh.com>:
>> 
>>> Hello list,
>>> 
>>> I thought I'd chime in since I am using Rucksack in a paid-for project
>>> (using LispWorks on Windows FWIW). I'm developing a client-server
>>> application that runs on an intranet, so there are only around a dozen
>>> users and the amounts of data are relatively small. Consequently I can
>>> (mostly) get away with just locking the entire store while I access
>>> it. Most access is serialised into one or two threads by virtue of the
>>> client-server nature anyway.
>>> 
>>> Rucksack has been great because it fits the task very nicely, and the
>>> fact it's all CL and doesn't need any external libraries/processes
>>> keeps things nice and simple (i.e. adding an index is as simple as
>>> recompiling the persistent class).
>>> 
>>> However I think it would be great to see it develop a little further,
>>> and I'd urge Jochen (and anyone else) to consider releasing their
>>> modifications that implement some basic multi-user access.
>>> 
>>> And thanks Arthur for doing such a great job with Rucksack in the first place!
>>> 
>>> Cheers,
>>> 
>>> John :^P
>>> --
>>> John Pallister
>>> john at johnp.net
>>> john at synchromesh.com
>>> 
>>> _______________________________________________
>>> rucksack-devel mailing list
>>> rucksack-devel at common-lisp.net
>>> http://common-lisp.net/cgi-bin/mailman/listinfo/rucksack-devel
>>