[Cl-perec-devel] Special requirements
Leslie P. Polzer
leslie.polzer at gmx.net
Thu Aug 21 17:27:19 UTC 2008
thanks for the answers so far.
> i'm not sure what you mean by processes. i assume OS processes and OS
> threads here, so multiple threaded lisp vm's.
Yes, I mean OS processes and threads.
> in perec persistent-objects are EQ inside a transaction, but separate
> transactions can not share anything, not even inside a lisp vm.
Will slot changes in one thread/process be seen by the other one?
I suppose a slot write will propagate immediately to the db, right?
Also, I'm not sure I understand the concept of dead/alive objects.
When is an object dead, and when is it alive?
> persistent instances are EQ inside a transaction but otherwise
> if you want to check object identity then you need to EQL check
> the id-of slot of the instances.
Good to know, thanks.
> perec is an rdbms mapper that helps you transfer data from/to the
> database. this also defines your possibilities. so, you can either
> separate your worlds using rdbms associations or useing different db
How would I use different databases with perec?
> i'm not sure about your requirements, but maybe the descriptions above
> give you a picture.
We're slowly getting there, I guess. :)
> bad idea... might work in progressive changes (e.g. making a column
> bigger), but what happens if the first restarted instance drops a
> column the others are expecting to be there...?
Yes, that's the case I'm worried about. But I guess I have to
invent something on my own here.
> but the multiple sides of associations are not working yet in
> transient instances (iow, transient collections are not yet
> implemented to store changes made to an association of a transient
Speaking of associations, have you pondered offering an alternative
interface to DEFASSOCIATION? This seems more natural to me:
(defpclass brother ()
((siblings :type (set siblings)))) ; hope I got the syntax right
More information about the cl-perec-devel