From tjg at pentaside.org Mon May 19 12:34:18 2008 From: tjg at pentaside.org (Tayssir John Gabbour) Date: Mon, 19 May 2008 14:34:18 +0200 Subject: [rucksack-devel] Rucksack's serializer: slot order problems? Message-ID: Hi! When storing a CLOS object, Rucksack's serializer seems to assume that class-slots returns the slots in the same order each time. (This is from my reading of rucksack:load-slots.) If so, then where does the MOP guarantee this? My reading of the MOP is that class-slots gets its value from compute-slots, which returns the slots "in unspecified order." Thanks for enlightenment, Tayssir From alemmens at xs4all.nl Thu May 22 09:57:33 2008 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Thu, 22 May 2008 11:57:33 +0200 Subject: [rucksack-devel] Rucksack's serializer: slot order problems? In-Reply-To: References: Message-ID: Hi Tayssir, > When storing a CLOS object, Rucksack's serializer seems to assume that > class-slots returns the slots in the same order each time. (This is > from my reading of rucksack:load-slots.) If so, then where does the > MOP guarantee this? > > My reading of the MOP is that class-slots gets its value from > compute-slots, which returns the slots "in unspecified order." Hmmm, very good point. I think you're right that the MOP doesn't guarantee a fixed order of the slots. So storing normal CLOS objects (i.e. instances of classes that don't have the PERSISTENT-CLASS metaclass) is not guaranteed to work correctly. At the moment it seems to be no problem in practice, but that's not good enough of course. I'm not sure about the best way to fix this. Here are some options: 1. Try to guarantee a fixed order for the slots, e.g. by sorting the list of slot names before saving or loading the slot values. This is probably the cheapest solution (in terms of speed and storage), and it should be easy to implement. But it can still fail after redefinitions of non-persistent classes. 2. Try to store and load some kind of schema info, just like we do for persistent classes. A bit more difficult to implement, but we can probably use most of the existing schema implementation, so it shouldn't be too difficult. It should also be able to handle class redefinitions. 3. Whenever we save a slot value, also save the slot name. This is simple and robust, but also seems very expensive. At the moment I'm inclined to go for solution #2, but I'd be interested in other opinions. > Thanks for enlightenment, Thank /you/ for enlightenment ;-) Arthur From tjg at pentaside.org Thu May 22 20:33:34 2008 From: tjg at pentaside.org (Tayssir John Gabbour) Date: Thu, 22 May 2008 22:33:34 +0200 Subject: [rucksack-devel] Rucksack's serializer: slot order problems? In-Reply-To: References: Message-ID: Hi Arthur! Arthur Lemmens wrote: > 2. Try to store and load some kind of schema info, just like we do for > persistent classes. > > A bit more difficult to implement, but we can probably use most of > the existing schema implementation, so it shouldn't be too difficult. > It should also be able to handle class redefinitions. Makes sense. So, during loading, a schema object always comes before the object it describes. And if DESERIALIZE-CONTENTS sees such a schema object, it'll silently stuff it into a table, and return the next normal object in the stream. Advantages that I can guess: * More robust "Slot mismatch" error than we have now. (If we simply change the order of slots in a class definition, it fails silently and corrupts the object.) * Upon slot mismatch, we can give (say) a restart to just do our best to load the damn object, with whatever slots are usable. ;) * This option #2 seems to have the best parts of the other two, without too much of their disadvantages. * If a bunch of objects of the same type were redefined to have different slots, no problem -- each will be preceded by a correct schema object. (Of course, I'm not that familiar with the other parts of Rucksack, so maybe I'm making no sense... ;) All best, Tayssir On Thu, May 22, 2008 at 11:57 AM, Arthur Lemmens wrote: > I'm not sure about the best way to fix this. Here are some options: > > 1. Try to guarantee a fixed order for the slots, e.g. by sorting the > list of slot names before saving or loading the slot values. > > This is probably the cheapest solution (in terms of speed and storage), > and it should be easy to implement. But it can still fail after > redefinitions of non-persistent classes. > > 2. Try to store and load some kind of schema info, just like we do for > persistent classes. > > A bit more difficult to implement, but we can probably use most of > the existing schema implementation, so it shouldn't be too difficult. > It should also be able to handle class redefinitions. > > 3. Whenever we save a slot value, also save the slot name. This is > simple and robust, but also seems very expensive. > > At the moment I'm inclined to go for solution #2, but I'd be interested > in other opinions. From ocorrain at gmail.com Tue May 27 16:35:48 2008 From: ocorrain at gmail.com (Tiarnan O'Corrain) Date: Tue, 27 May 2008 17:35:48 +0100 Subject: [rucksack-devel] state of the onion Message-ID: Hi-- what is the current status of rucksack? Is it considered to be stable and usable for (somewhat) important applications, or is it still in 'alpha' mode? thanks Tiarn?n From alemmens at xs4all.nl Tue May 27 18:57:44 2008 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Tue, 27 May 2008 20:57:44 +0200 Subject: [rucksack-devel] state of the onion In-Reply-To: References: Message-ID: Tiarnan O'Corrain wrote: > what is the current status of rucksack? Is it considered to be stable > and usable for (somewhat) important applications, or is it still in > 'alpha' mode? I'd say it's somewhere between alpha and stable ;-) Apart from the problem reported by Tayssir last week (see the mailing list archives), I'm not aware of any open bugs. Of course there's lots of room for improvement, but I guess there always will be. That said, I've only used Rucksack in situations where I could recreate the data from external sources when necessary and I still haven't used Rucksack for applications where data is critical. Nor have I heard from other people who have used Rucksack for such apps. So if you're planning to use Rucksack that way, I think it would be wise to tread carefully and make frequent back ups. Arthur From edi at agharta.de Tue May 27 19:45:34 2008 From: edi at agharta.de (Edi Weitz) Date: Tue, 27 May 2008 21:45:34 +0200 Subject: [rucksack-devel] state of the onion In-Reply-To: (Arthur Lemmens's message of "Tue, 27 May 2008 20:57:44 +0200") References: Message-ID: On Tue, 27 May 2008 20:57:44 +0200, "Arthur Lemmens" wrote: > So if you're planning to use Rucksack that way, I think it would be > wise to tread carefully and make frequent back ups. But you'd do that anyway, even if you were using Oracle, wouldn't you? To the OP: Does your decision really depend on the answers you get here? Whatever people say, you should try it out yourself and make your own evaluations. If the data you're working with is important, treat it carefully and make sure you always have backups. No matter which tools you use. And if you decide to use Rucksack, don't forget to send a report to this list. I might base my decision to use it on that... :) From rudi.engelbrecht at gmail.com Wed May 28 18:50:03 2008 From: rudi.engelbrecht at gmail.com (Rudi Engelbrecht) Date: Wed, 28 May 2008 20:50:03 +0200 Subject: [rucksack-devel] state of the onion In-Reply-To: References: Message-ID: <72A5EF22-E2AF-40BA-8921-6EC27894ADCD@gmail.com> Hi I am using Rucksack in an environment to help me construct quick prototypes in Lisp. I am initialising the database everytime I start up the environment at this stage. At the moment I create and manipulate about 50 domain objects during the startup (not plenty - I know). I was pleasantly surprised to have it downloaded and installed in less than 10 minutes in my LispWorks environment. So far - based on the minimal effort to get it going, the nice tutorial and the transparent approach to persistence it is a cheap way (in terms of development and setup) to add persistence. If your needs outgrow the solution, then you can always invest the time later to switch to something else. Rucksack's approach and seamless persistence reminds me a lot of GemStone Smalltalk. Kind regards Rudi On 27 May 2008, at 8:57 PM, Arthur Lemmens wrote: > Tiarnan O'Corrain wrote: > >> what is the current status of rucksack? Is it considered to be >> stable >> and usable for (somewhat) important applications, or is it still in >> 'alpha' mode? > > I'd say it's somewhere between alpha and stable ;-) > > Apart from the problem reported by Tayssir last week (see the mailing > list archives), I'm not aware of any open bugs. Of course there's > lots > of room for improvement, but I guess there always will be. > > That said, I've only used Rucksack in situations where I could > recreate > the data from external sources when necessary and I still haven't used > Rucksack for applications where data is critical. Nor have I heard > from > other people who have used Rucksack for such apps. So if you're > planning > to use Rucksack that way, I think it would be wise to tread > carefully and > make frequent back ups. > > Arthur > _______________________________________________ > rucksack-devel mailing list > rucksack-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/rucksack-devel > > From ocorrain at gmail.com Fri May 30 20:15:02 2008 From: ocorrain at gmail.com (Tiarnan O'Corrain) Date: Fri, 30 May 2008 21:15:02 +0100 Subject: [rucksack-devel] state of the onion In-Reply-To: <72A5EF22-E2AF-40BA-8921-6EC27894ADCD@gmail.com> References: <72A5EF22-E2AF-40BA-8921-6EC27894ADCD@gmail.com> Message-ID: Hi thanks to all for your replies. Of course I will do my own evaluation, but I wanted to test the water first. I'll give it a go. Thanks again Tiarn?n