Re: Divmod Axiom 0.5.20

On Mar 22, 2007, at 1:14 AM, Jean-Paul Calderone wrote:

> I can give an example of this if you like.  A specific use-case  
> would help
> guide such an example, since List provides a bunch of things, and  
> most use
> of it only relies on a few of these features.

Thanks for clarifying this! In most cases the sequence is not  
significant - all I really want to do is have a many-many  
relationship, and found List was a convenient way to do this. E.g. in  
the Axiom library.py example, If I wanted Books to be able to belong  
to many libraries then I might use a List. If you have a pattern you  
usually use for this kind of thing, I'd love to hear about it.


> Right now, there is a method which is
> called on each Item after a transaction in which it was changed has  
> been
> committed (named, unsurprisingly, "committed").

That's really handy....

>   Whether or not this is
> really a reliable, public feature of Axiom Items or not I don't  
> think is a
> completely settled question, though (for example, if you have two  
> processes
> using the same store and one changes an item, should the other  
> expect to get
> notified?  Perhaps not, but these questions should at least have  
> answers for
> them written down somewhere).

Yes, I imagine dealing with multiple processes accessing the same  
Store is going to be difficult!

> It will be interesting to see how it works out.  A major feature of  
> ZEO is
> distributed transactions.  It isn't yet clear to me how this would  
> work with
> Axiom.  Ignoring this, I don't see any major hurdles in getting a  
> ZEO-alike
> working with Axiom, but I'm not sure one can ignore it in practice. ;)

What I mostly care about is that remote objects on the client are  
kept in sync with changes to the Axiom database on server. I'm using  
pb.Copyable for most of my Items, when I probably should be using  
pb.Cacheable. Keeping pb.Cachables updated by doing it in the commit  
method you mentioned previously would probably not be that hard to do  
and would be good enough for my needs. Thing is, I use pb.Copyables  
because I don't just want to send these objects sever -> client and  
keep them updated, but I also allow clients to create them locally  
and send them to the server to be persisted. What I probably should  
do is sit down with the Twisted PB docs and rethink how I'm doing  
things. Maybe creating pb.Cacheable objects can be done on the server  
using a Twisted protocol (client requests to create empty object,  
fiddles with the attributes, then saves or discards). Anyway, I'm  
mixing a few problems together here and probably just confusing  
everyone.

If I come up with something decent, I'll let you know.

Robert