[Cl-perec-devel] Special requirements

[Attila Lendvai]

>> 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?


currently each slot change ends up in an sql update. it could be
optimized to gather slot changes until the transaction is actually
comitted, but it changes the semantics slightly and there are also
other lower fruits before that optimization.

what is visible in other transactions depends on the transaction
isolation level of your db and the timing of the lisp transactions.
your db is most probably in read-comitted unless you changed it, which
means that changes made in a transaction is not visible in other
transactions until it is comitted.


> Also, I'm not sure I understand the concept of dead/alive objects.
> When is an object dead, and when is it alive?


dead means that the transaction in which it was loaded in is already
closed. alive means that there's an open transaction in which this
instance is alive in. some operations don't work on dead instances
(i.e. accessors to not cached slots)


>> 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?


rebind *database* with different connection specification before using
a with-transaction block. (note that mixing different db types is not
supported/tested/etc, only different db instance of the same kind)


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


this should work already but it's not throughly tested because
associations don't have more cost than these slots and most of the
time it comes handy if you have a link in both directions. so we
mostly use associations.

-- 
 attila