[Cl-perec-devel] Special requirements

[Leslie P. Polzer]

Dear Attila,

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
> instances.

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
> instance)

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

  Leslie