-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Comments welcomed:

Not updated yet to cope with Durus 3.5 changes:
http://www.argo.es/~jcea/artic/know_how-durus-3_4.htm

Differences from 20060629 release:

"""
Index: KNOW_HOW-DURUS
===================================================================
- --- KNOW_HOW-DURUS      (revision 187)
+++ KNOW_HOW-DURUS      (working copy)
@@ -325,18 +327,43 @@
 starts with a "x" char :-).


- -### Weak references (20060424)
+### Weak references (20061003)

- -Persistent objects can't have weak references to other
- -persistent objects to ease garbage collection in the Storage. All
- -interobject references in the Storage will be strong.
- -
 Your program can keep internal (non persistent) weak references
 to persistent loaded instantes. Those references will be cleared
 automatically if necessary: cache shrink, conflicts, etc. You can
 keep such references across transactions boundaries.

+Persistent objects can't have weak references to other
+persistent objects to ease garbage collection in the Storage. All
+interobject references in the Storage will be strong.

+Nevertheless you can simulate sort-of weak references by hand
+using the internal OID of referenced persistent objects, since
+you can use the connection's "get()" method to load a persistent
+object given its OID. This manually managed reference doesn't
+preclude garbage collection of referenced objects if their reference
+count goes to zero. Just like standard weak references.
+
+Some details:
+
+- This usage pattern is not recommended by Durus developers. See
+  http://mail.mems-exchange.org/durusmail/durus-users/712/
+
+- Current Durus code does TWO database fetches when doing
+  connection's "get()". This is a Durus bug and should be
+  solved in a future release. See
+  http://mail.mems-exchange.org/durusmail/durus-users/701/
+
+- An object fetched via the connection "get()" is not strong
+  referenced, so it can vanish under your feet if other durus
+  client/thread makes its reference count go to zero.
+
+- Initially created persistent objects have no OID until
+  transaction commit, so you can't store their OID's until
+  commited by a previous transaction.
+
+
 ### Implicit object loading/dump (20060424)

 Transparent object loading/dumping is the key to a successful
@@ -509,6 +536,67 @@
 discussion in http://mail.mems-exchange.org/durusmail/durus-users/563/


+### BTree methods (20061003)
+
+Durus provides several persistent classes to use in your programs. The
+most interesting and "different" is BTree.
+
+BTree provides a (persistent) dictionary-like class. The main advantage
+is that a BTree is not fully loaded in RAM. Only the elements needed are
+fetched. So you can have an arbitrary huge BTree, without eating your RAM.
+
+As said, BTree is used like a normal python dictionary, but there are some
+additional useful features:
+
+- BTree keys are always kept sorted. So when you iterate over the elements,
+  you get them in order.
+
+- Some useful methods (some shared with python dictionaries, some BTree
+  specific features):
+
+  - "iteritems": Iterator over the (key,value) data in the BTree. Keys
+    are given in order.
+
+  - "items_from": Iterator over the (key,value) data in the BTree, starting
+    in the specified key. Keys are given in order.
+
+  - "items_backward": Iterator over the (key,value) data in the BTree.
+    Keys will be given in reverse order.
+
+  - "items_backward_from": Iterator over the (key,value) data in the BTree,
+    starting in the specified key. Keys are given in reverse order.
+
+  - "items_range": Iterator over the (key,value) data in the BTree, with
+    keys in the specified range. Keys are given in order.
+
+  - "iterkeys": Iterator over (key) data in the BTree. Keys are given
+    in order.
+
+  - "itervalues": Iterator over (value) date in the BTree. The values
+    are given in key order.
+
+  - "items": Give a list of (key,value) elements, in key order. Beware RAM
+    usage, if your BTree is big.
+
+  - "keys": Give a list of key elements, in key order. Beware RAM usage
+    if your BTree is big.
+
+  - "values": Give a list of value elements, in key order. Beware RAM
+    usage if your BTree is big.
+
+  - "__reversed__": Iterator over (key) data in the BTree, in inverse
order.
+
+  - "get_min_item": Gives the (key,value) pair with the minimal key in
+    the BTree. Since BTree's are stored sorted, this method is very fast.
+
+  - "get_max_item": Gives the (key,value) pair with the maximum key in
+    the BTree. Since BTree's are stores sorted, this method is very fast.
+
+  - "add": Add a new key->value to the BTree. Default "value" is "True".
+
+  - "has_key", "setdefault", "clear", "get", etc: Like python dictionaries.
"""

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea@jabber.org         _/_/    _/_/          _/_/_/_/_/
                               _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRSU1/Zlgi5GaxT1NAQJffgP/cnCgQSqhHU4hSZPO9dMjLM4RPgGVHKqY
O0QJgeXyeCwGHoJOllm4UdeXiBlJoo//n532PpskDS5oan24h/34lWIQ4z1kUfMY
yAwwcAZgQCBTeHqhcqR3DZSUEJS05LyXRdFFnU3KJydesSdEJ5Pb7q8pMaMGU4fx
+WtXfzhTNH4=
=m+BX
-----END PGP SIGNATURE-----