Hi, I was wondering if there anyone could recommend an object persistence layer that runs on LW? Thanks, Cam _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com http://www.lispworks.com/support/lisp-hug.html
Hi,
I was wondering if there anyone could recommend an object persistence layer that runs on LW?
Thanks,
Cam
_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html
Hi Camille, This is a terribly loaded question from you. You might find Rucksack totally adequate. I have used everything from simple persistence implemented on one page of code, to a Lisp version of Prevalence, to a full-blown OODBMS like Okeanos. In any event, they all rely on the ability to form portable serialized descriptions of objects, whatever an “object” means. Typically they have to deal with recursive or cross-referential structures. The paper on Prevalence that got me started was the one by Birrell, Jones, and Wobber from Digital Systems Research Center, “A Simple and Efficient Implementation for Small Databases”, Aug 1987. Prevalence takes the view that nearly all uses of databases, short of massive Hospital medical systems and Airline Reservation systems, can be held entirely in RAM with backing store to disk. Makes for a very fast system indeed. My version of Prevalence is a MetaClass on one page of code, and object instantiation on another page of code. Not much to it, once you have a persistent stream format worked out. That stream format is a whole other topic altogether, depending on how elaborate you need to make it become. Mine, developed over the past several decades handles every Lisp object you could think of, short of executable code. (code isn’t portable) I can provide copies of my stuff on request. But you need to further refine your desires. [ Prevalence seems to have taken on the name Prevaylor, Prevayler, etc. ] - DM > On Apr 11, 2016, at 07:38, Camille Troillard <camille.troillard@icloud.com> wrote: > > > Hi, > > I was wondering if there anyone could recommend an object persistence layer that runs on LW? > > > Thanks, > Cam > > > _______________________________________________ > Lisp Hug - the mailing list for LispWorks users > lisp-hug@lispworks.com > http://www.lispworks.com/support/lisp-hug.html > > _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com http://www.lispworks.com/support/lisp-hug.html
Hi Camille,
This is a terribly loaded question from you. You might find Rucksack totally adequate. I have used everything from simple persistence implemented on one page of code, to a Lisp version of Prevalence, to a full-blown OODBMS like Okeanos. In any event, they all rely on the ability to form portable serialized descriptions of objects, whatever an “object” means.. Typically they have to deal with recursive or cross-referential structures.
The paper on Prevalence that got me started was the one by Birrell, Jones, and Wobber from Digital Systems Research Center, “A Simple and Efficient Implementation for Small Databases”, Aug 1987. Prevalence takes the view that nearly all uses of databases, short of massive Hospital medical systems and Airline Reservation systems, can be held entirely in RAM with backing store to disk. Makes for a very fast system indeed.
My version of Prevalence is a MetaClass on one page of code, and object instantiation on another page of code. Not much to it, once you have a persistent stream format worked out. That stream format is a whole other topic altogether, depending on how elaborate you need to make it become. Mine, developed over the past several decades handles every Lisp object you could think of, short of executable code. (code isn’t portable)
I can provide copies of my stuff on request. But you need to further refine your desires.
[ Prevalence seems to have taken on the name Prevaylor, Prevayler, etc. ]
- DM
> On Apr 11, 2016, at 07:38, Camille Troillard <camille.troillard@icloud.com> wrote:
>
>
> Hi,
>
> I was wondering if there anyone could recommend an object persistence layer that runs on LW?
>
>
> Thanks,
> Cam
>
>
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> lisp-hug@lispworks.com
> http://www.lispworks.com/support/lisp-hug.html
>
>
_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html
Unable to parse email body. Email id is 13783
The way I’ve solved this in the past is to include within the closed-over objects functions to save/restore state to a file and then use initializations to do so at appropriate times (e.g., at warm start). But you’re right, it’s not general to all closures, only those you write yourself to do so. — Bradford W. Miller Sr. Cognition and Decision Scientist Co-Chair Industrial Internet Consortium Technology Working Group GE Global Research Robotics and M2M Systems The Lab Formerly Known as Distributed Intelligent Systems 518 387-4271 millerb@ge.com http://www.geglobalresearch.com/blog/brilliant-machines > On Apr 12, 2016, at 8:03 AM, Madhu <enometh@meer.net> wrote: > > Persisting source (code is data) and even fasls is fine. But there is > one very important class of first class lisp objects representing > "code", namely closures, which just cannot be serialized, and which > can only be persisted by saving and restarting the lisp image. This > effectively puts design and style restrictions on programs which use > object persistence systems to persist code.. _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com http://www.lispworks.com/support/lisp-hug.html
Maintenance of state across device or system restarts/resets. Sent from my iPhone > On Apr 12, 2016, at 1:46 PM, Mike <azmikeg@gmail.com> wrote: > > > How about if each of you that have responded to this inquiry in the past week or so provide a clear, rigorous definition of what each of you mean by the term "Persistence"? I have seen it done by a something as gross as a repeating "do" loop to actively being sure things are kept in memory. > > Peace, > Mike G. > > > >> > > > _______________________________________________ > Lisp Hug - the mailing list for LispWorks users > lisp-hug@lispworks.com > http://www.lispworks.com/support/lisp-hug.html > _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com http://www.lispworks.com/support/lisp-hug.html
Thank you all for your answers. I have been intentionally vague about my question, because I wanted to see where the discussion was naturally going. The discussion about closure persistence is very interesting. The meaning I gave to object persistence in my previous question was just as Bradford so simply stated “the maintenance of state across device or system restarts/resets”. I was curious to know what were the projects in CL that enabled object graphs persistence in the most natural way: I have a graph of domain objects and I just want to persist them, and query the database to extract sub-graphs. The was once a great ORM called Enterprise Objects Framework (invented by NeXT, now part of Apple’s Foundation and named CoreData, with a few changes). This was great : you define a model that expressed the mapping between your relational database and your domain entities, and you’re done : the framework handle object identity (Uniquing) and lazy fetch (faulting). It was GREAT. Now, I recently began to look at graph databases and thought that the mapping between objects stored in the database and the domain objects was a trivial use-case. It turns out that this is not the case: there is not object graph mapper (OGM) that currently satisfies the basic need for uniquing (every time you do a fetch, you get new objects), and faulting (you can’t traverse your graph just by walking the objects relationship, you have to express all queries and fetch a new sub-graph). So, I was wondering how this was done in the good old world of Lisp, CLOS seems to be such a great fit for this… Best, Cam > On 12 Apr 2016, at 19:46, Mike <azmikeg@gmail.com> wrote: > > > How about if each of you that have responded to this inquiry in the past week or so provide a clear, rigorous definition of what each of you mean by the term "Persistence"? I have seen it done by a something as gross as a repeating "do" loop to actively being sure things are kept in memory. > > Peace, > Mike G. > > > >> > > > _______________________________________________ > Lisp Hug - the mailing list for LispWorks users > lisp-hug@lispworks.com > http://www.lispworks.com/support/lisp-hug.html > _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com http://www.lispworks.com/support/lisp-hug.html
Thank you all for your answers.
I have been intentionally vague about my question, because I wanted to see where the discussion was naturally going. The discussion about closure persistence is very interesting.
The meaning I gave to object persistence in my previous question was just as Bradford so simply stated “the maintenance of state across device or system restarts/resets”. I was curious to know what were the projects in CL that enabled object graphs persistence in the most natural way: I have a graph of domain objects and I just want to persist them, and query the database to extract sub-graphs.
The was once a great ORM called Enterprise Objects Framework (invented by NeXT, now part of Apple’s Foundation and named CoreData, with a few changes). This was great : you define a model that expressed the mapping between your relational database and your domain entities, and you’re done : the framework handle object identity (Uniquing) and lazy fetch (faulting). It was GREAT.
Now, I recently began to look at graph databases and thought that the mapping between objects stored in the database and the domain objects was a trivial use-case. It turns out that this is not the case: there is not object graph mapper (OGM) that currently satisfies the basic need for uniquing (every time you do a fetch, you get new objects), and faulting (you can’t traverse your graph just by walking the objects relationship, you have to express all queries and fetch a new sub-graph).
So, I was wondering how this was done in the good old world of Lisp, CLOS seems to be such a great fit for this…
Best,
Cam
> On 12 Apr 2016, at 19:46, Mike <azmikeg@gmail.com> wrote:
>
>
> How about if each of you that have responded to this inquiry in the past week or so provide a clear, rigorous definition of what each of you mean by the term "Persistence"? I have seen it done by a something as gross as a repeating "do" loop to actively being sure things are kept in memory.
>
> Peace,
> Mike G.
>
>
>
>>
>
>
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> lisp-hug@lispworks.com
> http://www.lispworks.com/support/lisp-hug.html
>
_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html
Hi Robert, > On 13 Apr 2016, at 14:44, Robert P. Goldman <rpgoldman@sift.net> wrote: > > I looked at that github page, and the code is clearly labeled with copyright and proprietary legends. I can't imagine Symbolics being harmed by someone using it, but it's clearly not legal. The code is almost empty. It’s just systems and packages declarations. Am I missing something? Cam _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com http://www.lispworks.com/support/lisp-hug.html
Hi Camille, we use at work a system very like the one you describe. Its built upon sql:def-view-class in lispworks CL, which provides for the uniqueness and graph walking across joins. The code I work on adds application specific, directed, typed links to represent functional dependencies. There's also code to communicate object changes to other lisp images connected to the same database. Unfortunately neither are open source but the product does see use by large corporations today; CLOS is definitely up to the challenge.
Cheers for starting such an interesting thread.
Andrew Kirkpatrick
Thank you all for your answers.
I have been intentionally vague about my question, because I wanted to see where the discussion was naturally going. The discussion about closure persistence is very interesting.
The meaning I gave to object persistence in my previous question was just as Bradford so simply stated “the maintenance of state across device or system restarts/resets”. I was curious to know what were the projects in CL that enabled object graphs persistence in the most natural way: I have a graph of domain objects and I just want to persist them, and query the database to extract sub-graphs.
The was once a great ORM called Enterprise Objects Framework (invented by NeXT, now part of Apple’s Foundation and named CoreData, with a few changes). This was great : you define a model that expressed the mapping between your relational database and your domain entities, and you’re done : the framework handle object identity (Uniquing) and lazy fetch (faulting). It was GREAT.
Now, I recently began to look at graph databases and thought that the mapping between objects stored in the database and the domain objects was a trivial use-case. It turns out that this is not the case: there is not object graph mapper (OGM) that currently satisfies the basic need for uniquing (every time you do a fetch, you get new objects), and faulting (you can’t traverse your graph just by walking the objects relationship, you have to express all queries and fetch a new sub-graph).
So, I was wondering how this was done in the good old world of Lisp, CLOS seems to be such a great fit for this…
Best,
Cam
> On 12 Apr 2016, at 19:46, Mike <azmikeg@gmail.com> wrote:
>
>
> How about if each of you that have responded to this inquiry in the past week or so provide a clear, rigorous definition of what each of you mean by the term "Persistence"? I have seen it done by a something as gross as a repeating "do" loop to actively being sure things are kept in memory.
>
> Peace,
> Mike G.
>
>
>
>>
>
>
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> lisp-hug@lispworks.com
> http://www.lispworks.com/support/lisp-hug.html
>
_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html
"Robert P. Goldman" <rpgoldman@sift.net> writes: > I looked at that github page, and the code is clearly labeled with > copyright and proprietary legends. I can't imagine Symbolics being > harmed by someone using it, but it's clearly not legal. Well, given that Symbolics is dead and already 99% decomposed, indeed, no harm can be done to it. You only risk being haunted by its ghost the "intellectual" and "copy" rights owner. -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com http://www.lispworks.com/support/lisp-hug.html
On 4/13/16 Apr 13 -1:24 PM, Pascal J. Bourguignon wrote: > > "Robert P. Goldman" <rpgoldman@sift.net> writes: > >> I looked at that github page, and the code is clearly labeled with >> copyright and proprietary legends. I can't imagine Symbolics being >> harmed by someone using it, but it's clearly not legal. > > Well, given that Symbolics is dead and already 99% decomposed, indeed, > no harm can be done to it. You only risk being haunted by its ghost the > "intellectual" and "copy" rights owner. > According to Wikipedia: Symbolics refers to two companies: now-defunct computer manufacturer Symbolics, Inc., and a privately held company that acquired the assets of the former company and continues to sell and maintain the Open Genera Lisp system and the Macsyma computer algebra system.[2] If it was me, I would take down that github repo. I certainly wouldn't fork it, and I wouldn't incorporate any code I found there in anything I was building.... cheers, r _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com http://www.lispworks.com/support/lisp-hug.html
[Only just catching up] There is an object persistence layer in https://github.com/mbattyani/cl-fff Mostly here: https://github.com/mbattyani/cl-fff/tree/master/meta It has backends for various kind of storage that can be used simultaneously: text files store, postgresql, mongodb and it does a lazy loading of the objects data to avoid pulling everything in memory at once. I generally use the text files store for simple stuff that doesn't contain too many objects. For instance http://www.cl-user.net/ uses that text files store but grew up to around 10k objects which is probably too much. In fact this does much more than only persistence and it's probably overkill for only object persistence. Marc On 4/13/16 04:22, Camille Troillard wrote: > Thank you all for your answers. > > I have been intentionally vague about my question, because I wanted to see where the discussion was naturally going. The discussion about closure persistence is very interesting. > > > The meaning I gave to object persistence in my previous question was just as Bradford so simply stated “the maintenance of state across device or system restarts/resets”. I was curious to know what were the projects in CL that enabled object graphs persistence in the most natural way: I have a graph of domain objects and I just want to persist them, and query the database to extract sub-graphs. > > The was once a great ORM called Enterprise Objects Framework (invented by NeXT, now part of Apple’s Foundation and named CoreData, with a few changes). This was great : you define a model that expressed the mapping between your relational database and your domain entities, and you’re done : the framework handle object identity (Uniquing) and lazy fetch (faulting). It was GREAT. > > Now, I recently began to look at graph databases and thought that the mapping between objects stored in the database and the domain objects was a trivial use-case. It turns out that this is not the case: there is not object graph mapper (OGM) that currently satisfies the basic need for uniquing (every time you do a fetch, you get new objects), and faulting (you can’t traverse your graph just by walking the objects relationship, you have to express all queries and fetch a new sub-graph). > > So, I was wondering how this was done in the good old world of Lisp, CLOS seems to be such a great fit for this… > > > Best, > Cam > > >> On 12 Apr 2016, at 19:46, Mike <azmikeg@gmail.com> wrote: >> >> >> How about if each of you that have responded to this inquiry in the past week or so provide a clear, rigorous definition of what each of you mean by the term "Persistence"? I have seen it done by a something as gross as a repeating "do" loop to actively being sure things are kept in memory. >> >> Peace, >> Mike G. >> >> >> >> >> _______________________________________________ >> Lisp Hug - the mailing list for LispWorks users >> lisp-hug@lispworks.com >> http://www.lispworks.com/support/lisp-hug.html >> > > _______________________________________________ > Lisp Hug - the mailing list for LispWorks users > lisp-hug@lispworks.com > http://www.lispworks.com/support/lisp-hug.html > _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com http://www.lispworks.com/support/lisp-hug.html