Thanks for the clear example. However, maybe the idioms are confusing me, but many-to-many tells me that I should be able to do something like:
(setf (friends-of person1) person2) (setf (friends-of person1) person3) (setf (friends-of person1) person4) (setf (friends-of person1) person5) (setf (friends-of person2) person3) such that: (friends-of person1) => (person2 person3 person4 person5) (friends-of person2) => (person1 person3) (friends-of person3) => (person1 person2) (friends-of person4) => person1 (friends-of person5) => person1 Would that be the expected behavior? Best regards, JD On Tue, Jan 27, 2009 at 3:22 PM, Ian Eslick <esl...@media.mit.edu> wrote: > Slot associations appear to work reflexively, by the way. > > (defpclass self-assoc () > ((friends-of :accessor friends-of > :associate (self-assoc friended-me) > :many-to-many t) > (friended-me :accessor friended-me > :associate (self-assoc friends-of) > :many-to-many t))) > > This simply says I have an association among self-assoc instances. > Any (setf (friends-of person1) person2) says that person2 is a friend- > of person1. Automatically, you get the inverse mapping which is that > person1 friended person2 (assuming these associations are directional). > > If they are not directional, then you can do this: > (defpclass person () > ((friends :accessor friends-of > :associate (person friends) :many-to-many t))) > > Now if you (setf (friends-of person1) person2), you will get: > > (friends-of person1) => person2 > (friends-of person2) => person1 > > This is a non-directional relationship between two entities so there's > no need for two slots. > > This all seems to work well in the current Alpha 2. > > Ian > > On Jan 27, 2009, at 1:32 PM, Ian Eslick wrote: > > > > > On Jan 27, 2009, at 11:00 AM, John wrote: > >> > >> 1) Every read/write of pclass slots is done directly from/to the > >> database, so no in-memory "copy" exists (unless some sort of > >> transient cache slot model is used). This is good. However, is > >> Elephant "intelligent" enough so that if you attempt to setf a slot > >> value with the same value stored in the slot, Elephant will "avoid" > >> the writing to the database, since the value hasn't really changed? > >> If that's not the out-of-the-box behavior, I pressume that it would > >> be relatively easy to add this functionality using MOP. I also > >> assume that doing this will require another read before the write in > >> order to compare the value to be written, but then again, Elephant > >> claims that reads are much cheaper than writes. > >> > > > > Such a thing would be possible, but you would need to have a local > > copy of the value in memory and this could create more problems than > > it solves. It's also unclear to me how common this case. I don't > > write the same value to the same slot very often! > > > >> 2) According to Oracle: "Berkeley DB includes support for building > >> highly available applications based on replication..." ( > http://www.oracle.com/technology/documentation/berkeley-db/db/ref/rep/intro.html > >> ) So, I assume that in the event that a single machine becomes > >> unable to handle the load of a busy application, BDB supports > >> replication to multiple machines with near-instant replication > >> effects (performance is inversly proportional to replication speed). > >> So, the question is, can Elephant accommodate to this model? If I > >> read correctly, the manual states that elephant maintains a weak > >> hash of persistent objects. So, if BDB is deployed in a distributed > >> model and Elephant is running in each separate machine, we could in > >> theory "trust" that the data read/written from/to disk will be all > >> in sync across all machines (as long as database IO on same object/ > >> slot occurs at a frequency greater than the replication rate). The > >> question I have is with the weak hash. If a write is made in one > >> machine, the data on disk is updated across all machines. However, > >> the weak hash remains stale in the machines were the data was only > >> replicated to. Is this an actual problem or does Elephant use the > >> weak hash "intelligently" to recover in the event that the weak hash > >> becomes "unexpectedly" stale? > > > > The weak hash is simply used to speed up the 'recreation' of a > > persistent reference when it is deserialized from the underlying > > storage medium (BDB in this case) so fits into this model. I've > > looked several times at building-in the support to enable a full > > replication model for BDB, but it's a fair bit of work to deal with > > the single-master requirement for replication and distributed > > transactions for global coherence. The write performance and > > contention performance may decline noticeably, but conflict-free read > > performance should be the same as in the non-replicated case. I don't > > fully understand all these issues yet and am prioritizing a lisp-only > > Prevalence style backend in my development roadmap. > > > >> 3) I come from a RDBMS world, so I'm still learning the modalities > >> of connected objects vs just related rows. So, reading the tutorials > >> you describe a friends model using PSets. So, imagine a concept > >> similar to Facebook in terms of a friends database. I have millions > >> of people created in the system and they all create their list of > >> friends. Some people may have "few" or no friends while others could > >> have hundreds of thousands of friends (e.g. Pres. Obama). Are PSets > >> the correct way to model this for larger number of objects or is > >> there a more appropriate methodology recommended in Elephant? > >> Obviously the idea behind this is so that you could perform > >> manipulations on these "friends" relatively easy, such as add/remove > >> friends or perform global queries as to list all friends of people > >> who are friends of Pres. Obama. There are references on the list > >> about a query system being worked on and some vanilla version being > >> available, but independently of that, I think my question is more > >> related to the object model implementation. Maybe I'm wrong. > > > > Psets today are a convenience API around the BTree that can be > > overridden by data stores later for more efficient implementation > > (e.g. hash vs. tree) as appropriate for that store. BTrees are cheap > > for BDB to create and use so use of them at any size is fine. You > > might want to wrap an abstraction around the BTree directly since the > > pset API is an un-ordered set. If you want to do range extraction or > > set intersection you'll want the btree's support for ordered objects. > > > > The query system currently doesn't support psets, although it should > > eventually. > > > > Slot-associations currently don't deal with reflexive references > > (associations among instances of a single class), but that would also > > address the 'friends-of' problem. > > > > I hope you enjoy elephant! If you want to add/implement or spec out > > some of these changes you are thinking about, I'd be happy to support > > you. > > > > Cheers, > > Ian > > > >> Anyway, thank you for your help in advanced. Look forward to hearing > >> back from anyone soon and keep learning more about Elephant. > >> > >> Thanks, > >> JD > >> _______________________________________________ > >> elephant-devel site list > >> elephant-devel@common-lisp.net > >> http://common-lisp.net/mailman/listinfo/elephant-devel > > > > > > _______________________________________________ > > elephant-devel site list > > elephant-devel@common-lisp.net > > http://common-lisp.net/mailman/listinfo/elephant-devel > > > _______________________________________________ > elephant-devel site list > elephant-devel@common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel >
_______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
