Re: Divmod Axiom 0.5.20

On 04:16 am, [email protected] wrote:
>
>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.

The pattern is just to create Item subclasses to represent these 
relationships, and then write methods or functions as appropriate to 
query them.  To follow your example of books which "belong to many 
libraries", in actuality, the books are likely to be the targets of 
lend/lease arrangements between the libraries.

Here's a concrete example of what I mean:

    class Lease(Item):
        """
        A library may lease a book; this represents that relationship.
        """
        book = reference()
        library = reference()

    class Book(Item):
        def getLibraries(self):
            """
            Return an iterable of libraries where a book may be borrowed.
            """
            return self.store.query(Lease, Lease.book == self)

It might be nice to have some explicit support for this so that you 
could have a 'libraries' attribute on Book which would automatically 
generate such a query, but getting the nuances of such an API right is 
quite difficult.  Writing the ad-hoc queries is generally pretty simple.
>Yes, I imagine dealing with multiple processes accessing the same 
>Store is going to be difficult!

The main thing you need to be aware of is that a Store is a cache of 
data.  If you don't let your items get garbage collected, you'll end up 
hanging on to stale data from previous transactions.  In all of our 
multi-process applications so far, one store is responsible for an 
object at a time.
>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.

Making asynchronous, performant, distributed, transactional software 
systems is pretty much the most complex thing that mankind has ever 
attempted.  I wouldn't be worried if it seems a bit hard :).
>If I come up with something decent, I'll let you know.

Please do.  This list could use some more traffic; as you mentioned, it 
seems like there isn't much going on, but in fact everything is being 
very actively and rapidly improved.  It'd be good to get some more 
feedback from our users about how things are being used.