Re: Divmod Axiom 0.5.20

On Wed, 21 Mar 2007 17:43:48 +0900, Robert Gravina <[email protected]> wrote:
>Oh wow... I was under the impression Axiom development wasn't really 
>happening, until I decided to look at trunk about a week ago and  realised 
>you guys were up to version 0.5.19!
>
>In the meantime, I dabbled with sqlalchemy but came back to Axiom in 
>frustration. Axiom is so much simpler to work with, and more powerful  in 
>some areas that matter to me (e.g. abstraction).
>

 :)

>I'll definitely upgrade to 0.5.20 (and Epsilon 0.5.6).
>
>I noticed there is a "whenDeleted=CASCADE" option for references from  the 
>fact there was a ticket about it being slow...
>This is great  news, because 
>I have a lot of code which deletes the children of an  object by defining 
>onDeleteItem (for child in self.children:  child.deleteFromStore() kind of 
>thing) and it would be nice to get  rid of some of that code (e.g. what if I 
>forget to delete something?  It's great that the DB handles it).
>http://divmod.org/trac/ticket/1864
>
>Also I noticed a ticket saying the that axiom.sequences.List is 
>depreciated... I use it extensively... what is the suggested way to 
>implement similar functionality?
>http://divmod.org/trac/ticket/1507

The issue here is just that providing list-like semantics on top of SQL
is very inefficient.  Rather than leave this around for people to stumble
into and then wonder why their application is so slow, I think it's better
to not provide it at all.

Of course, that leaves the question of what to do instead.  Basically, if
you don't depend on sequence numbers (ie, list indices), then you can use
something simpler and faster than List, albeit something which is only a
pattern at this point, not an Axiom library feature.  If you _do_ depend
on sequence numbers, then List is actually close to as good as it gets. I
would suggest trying not to depend on sequence numbers. :)

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.

>
>The app I am writing uses Axiom, Twisted Perspective Broker and  wxPython so 
>that several clients can share data and edit certain  objects through GUI 
>forms. Most Items subclass pb.Copyable so users  can add new object locally 
>by creating a pb.RemoteCopy that doesn't  subclass from Item, but has the 
>same attributes as the Item and  shares data validation code. When they are 
>done setting editing this  newly-created object, they send to the server 
>where I create the Item/ pb/Copyable version of that object and copy all the 
>attributes across  (pb.Cacheables need to be created/live on the server, so 
>I'm not sure  how to do this using them) and I notify all clients after the 
>Item is  saved.
>
>Is there any way to find out which objects have been updated when a 
>transaction is committed? I thought perhaps I could have certain Item/ 
>pb.Cacheable subclasses define an "update" method which gets called  right 
>after a transaction is committed and updates clients.

If you really want to use Axiom this way, there should probably be some
explicit support for this feature.  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").  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).

>
>Essentially, what I would like to do is implement something like  Zope's ZEO 
>but with Twisted and Axiom.  Am I totally nuts? Would  Glyph or others have 
>any suggestions before I give this a try? For  the purposes of my app I can 
>get by just writing code to update  clients on a case-by-case basis when 
>each type of major Item in my  application is saved, but it would be nice to 
>work on something more  generic that I (and others) can reuse. I don't want 
>to switch to ZEO,  because that would mean restarting from scratch 
>essentially and I do  like Twisted!

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. ;)

Jean-Paul