[ZODB-Dev] AdaptableStorage questions...

[Chris Withers]

[picking up some questions from a whiel abck and moving them to the zodb-dev list]

Shane Hathaway wrote:

 >> Say you want
 >> to perform a search, and you really want to use SQL to perform this
 >> search ('cos the search is easy and efficient to write in SQL and
 >> returns things nicely sorted as required) but you want 'real objects'
 >> back from the search.
  >>
 >> How about the following?
 >>
 >> def query(self,*args,**kw):
 >>    # the parameters depend on how the mount point's mapping
 >>    # is set up.
 >>    # for SQL, it might just take a query string of the form:
 >>    # SELECT customer.id FROM customer,contact,address WHERE ...
 >>    paths_relative_to_mount_point = self.doQuery(*args,**kw)
 >>    # doQuery would have to come from the configuration
 >>    return map(self.restrictedTraverse,paths_relative_to_mount_point)
 >>
 >> Would that be cool?
 >
 > Yes, that's a good approach.  I think that's what I would do.

Great, what needs to be added to AS to make it real?

 >> PS: Has anything happened for the 'bottom invalidation' stuff? ie:
 >> When the data changes on disk or in SQL, AS gets notified so it can
 >> dump the objects from the ZODB cache...
 >
 > I haven't added this yet.  Still pondering.

Anything we can help with?

 > How will AS handle undo? I see currently objects have no undoable 
transactions, is it possible to configure AS such that they could have if either 
the back end supports undoable transactions or could be made to look like it 
does (by storing old revisions somewhere, for example...)
 >
 > No undo.  I don't want to think about that yet.

I'm guessing Undo would be a version 2.0 feature?

  >> How is it best to handle non-transactional back ends with AS? The
  >> two that spring to mind are FS and MySQL mappings. What happens to
  >> data already written to the storage if a ZODB transaction is aborted?
  >
  > FSConnection writes nothing until the second phase of transaction
  > commit.  It tries to detect error conditions during the first phase.  So
  > data can be partially committed, but it's unlikely.  For people who use
  > the filesystem, that's an acceptable risk.

Could code be added to delete partially committed data?

  > MySQL has transactions now, doesn't it?  I'm sure I read that it did.

Yes, but I'm very interested in the case where someone already has a big MySQL
database that's not transactional. What would happen there?

cheers,

Chris