[ZODB-Dev] Best use for an OOBTree

[dvd]

Hi all,
I'm trying to figure out the best use for an OOBTree, but I need some
help.

I'm writing a framework around ZODB, this framework must have a
hierarchy concept of users.

Example:

An application can manipulate objects A and B, I could have three users
U1, U2 and U3.
U1 and U2 read and modify different instances, U1 cannot read or modify
U2 objects and vice-versa.
U3, otherwise, is a parent of U1 and U2, and can read all his own
children objects.

My doubt is:

Is it better:
1. to have a *big* OOBTree that collects all the objects, and then keep
in U1 and U2 an OOBTee of ids referring
the objects in the big one. 

2. keep separate the U1 and U2 objects and let U3 search through all
child OOBTree

The second choice looks more simple to implement, but it increases the
complexity of U1 searches.

thank you for any ideas (and sorry for my poor English)
david




signature.asc
Description: This is a digitally signed message part
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

RE: [ZODB-Dev] misleading exception

[dvd]

On Sun, 2005-11-06 at 18:48 -0500, Tim Peters wrote:
 [dvd]
  Hi all, I'm still working with savepoints and today I spend about tewo
  hours to find an error, misleaded by a strange Exception
 
 As Dieter said (thanks, Dieter!), the current transaction should always be
 explicitly committed or aborted before closing any Connection involved in
 the transaction.  ZODB tries to raise ConnectionStateError if you close a
 Connection without explicitly finalizing the transaction, but something
 about savepoints isn't getting caught here.  I'm not positive it _should_
 raise ConnectionStateError in this case.  But, if it doesn't, then it should
 guarantee to clean up all the bits left behind by the savepoint machinery.

Thank you for the answer
little by little I understand more details


 BTW, your code used a mixture of tabs and spaces for indentation.  That's a
 Bad Idea for code posted to a mailing list.  All-tabs or all-spaces works
 much better.  The Python and Zope projects' standards mandate 4-space
 indents (with no hard tab characters).

I use on top of my files
# vim: expandtab sw=4 ts=4 sts=4 foldmethod=indent:

but i forget a :retab
:)

 
  fstorage = FileStorage.FileStorage(fname)
  db = DB(fstorage)
  try:
  conn = db.open()
  try:
  try:
 
 That's an example of why mixing tabs with spaces sucks.  I can't know what
 that looks like in _your_ email reader, but in _mine_ it looks like both
 try: statements are indented the same.

you are right, sorry for the inconvenient

[snip]
 While I think this is obscure, closing a DB automatically closes the storage
 it wraps.  My natural inclination is also to close both explicitly, but I
 get ragged on for that -- the `fstorage.close()` isn't necessary.

I read the documentation, but I miss this info

 
  ...
  The strange is that the exception is raised when i try to commit the
  transaction in the second call of CreateDatabase
 
 You confused the transaction machinery, that's all wink.

probably :)




signature.asc
Description: This is a digitally signed message part
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

[ZODB-Dev] strange savepoint behavior

[dvd]

Hi all,

I'm writing a framework on top of ZODB and I'm now investigate on a
strange savepoint-related behavior (after a savepoint.rollback the
attributes of a Persistent-derived class disappears)

While investigate i write this code and found another strange behavior
(maybe correlated?)

* CODE *

from ZODB import FileStorage, DB
from persistent import Persistent
from BTrees.OOBTree import OOBTree
import transaction

dbname = '/tmp/test.db'
fstorage = FileStorage.FileStorage(dbname)
db = DB(fstorage)
conn = db.open()
root = conn.root()

class Word(Persistent):
def __init__(self, word, id):
super(Word, self).__init__()
self.id = id
self._word = word

data = root['data'] = OOBTree()

commonWords = []
count = 0
for x in ('hello', 'world', 'how', 'are', 'you'):
commonWords.append(Word(x, count))
count = str(int(count) + 1)

sv = transaction.savepoint()
for word in commonWords:
sv2 = transaction.savepoint()
data[word.id] = word

sv.rollback()

print commonWords[1].id

* END CODE *

if i run this snippet, the last line (print ...) raise a POSKeyError

It works nicely if i omit the sv2 = transaction.savepoint() line or if
the Word class is a subclass of object

Have you any idea?

david


signature.asc
Description: This is a digitally signed message part
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

RE: [ZODB-Dev] strange savepoint behavior

[dvd]

On Thu, 2005-11-03 at 09:44 -0500, Tim Peters wrote:
 You didn't say which version of ZODB you're using, but I doubt it matters:
 I was able to reproduce the POSKeyError in the current ZODB 3.6 branch.

I'm using ZODB 3.5.1

 
 I expect it's an artificial glitch due to never committing anything (i.e.,
 an extreme case some part of the code just isn't expecting).  If I add
 
 transaction.commit()
 
 right after your
 
 data = root['data'] = OOBTree()
 
 then the POSKeyError goes away, and I get
 
 Traceback (most recent call last):
   File pos_dvd.py, line 34, in ?
 print commonWords[1].id
 AttributeError: 'Word' object has no attribute 'id'
 
 instead.  That makes sense to me:  rolling back invalidates the in-memory
 Word objects, and they lose all their user-defined attributes then.  Since
 the object states were never committed (except to savepoints that were
 explicitly thrown away), there's no way to get the attributes back.

great! this is exactly the error that i'm trying to reproduce
so is this an expected behavior (the lost of the attributes)?
this sounds a bit strange to me, let me explain:

with:
 CODE 
sv = transaction.savepoint()
for word in commonWords:
sv2 = transaction.savepoint()
data[word.id] = word
**

the last line (print ) raise an AttributeError:

with:
 CODE 
sv = transaction.savepoint()
for word in commonWords[0:1]:
sv2 = transaction.savepoint()
data[word.id] = word
**

all works fine (no AttributeError)

obviously if i omit the second savepoint, all works fine

if rolling back invalidates the in-memory objects, why without the
second savepoint the id attribute still exists?

thank you
david


signature.asc
Description: This is a digitally signed message part
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

RE: [ZODB-Dev] know the state of an object

[dvd]

On Thu, 2005-10-13 at 19:04 -0400, Tim Peters wrote:

  from the connection object,
 
 You didn't say which version of ZODB you're using.  Since you believe
a
 Connection keeps track of which objects have been modified, I'll
assume
 you're using ZODB 3.3 or later (which is either true, or your belief
about
 who keeps track of modified objects is false ;-)).

yup i missed this info, i'm using zodb 3.4

 
  so i overload the __setattr__ method in my base-class and keep track
  of the modified objects
 
  But that's the problem, __setattr__ is called also when ZODB loads
the
  objects from the storage and reconstructs it, so is there a way to
know
  the state of the object (unpickilng, modified, clean etc etc)?
 
 The good news is that obj._p_state reveals the current state of a
persistent
 object.  The possible values are exposed by the `persistent` module:

I see, yesterday, after my message obviously, i see the light and write
this code

class PersistentObject(Persistent):
[... some code ...]
def __setattr__(self, attr, value):
if not self._p_setattr(attr, value):
super(PersistentObject, self).__setattr__(attr, value)

if not attr.startswith('_p_') and self._p_changed and attr!
='_Modified':
self.Touch()


 So, in the end, I don't see any hope for you via this route, short of
this:
 register an object as changed in your __setattr__ without worrying at
all
 about _why_ __setattr__ was called.  Later, when you do something
with
 your list of modified objects, simply ignore any whose state at that
time is
 UPTODATE.  Those are exactly the objects whose state got materialized
but
 didn't change thereafter.

Ok, thank you for your help

bye

___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

[ZODB-Dev] know the state of an object

[dvd]

Hi all,

this my first post to this list, and first of all thanks for your work.

I'm developing a ZODB based Collection Management software, and, for a
bunch of reasons, i have to know the list of modified objects before the
current transaction commit. Looking around seems there is no a public
API to obtains this list from the connection object, so i overload the
__setattr__ method in my base-class and keep track of the modified
objects

But that's the problem, __setattr__ is called also when ZODB loads the
objects from the storage and reconstructs it, so is there a way to know
the state of the object (unpickilng, modified, clean etc etc)?

thank you
david

___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev