Re: [Zope] Questions on ZODB BTrees versus bsddb BTrees
Hi Chris
"Chris" == Chris Withers <chris@simplistix.co.uk> writes: You may Chris> have more joy with these questions on the zodb-dev@zope.org mailing Chris> list...
Thanks, I've re-sent. Thanks for the other comments & pointers too. Regards Terry.
- ZODB BTrees do not allow you to set up secondary keys (a la bsddb). Chris> Dunno what that means. I think you're just use two BTrees for this...
[Sorry if the following is off-topic for the list. It's presumably good for the archives, and, I suppose, is the end of the thread.]
From the Berkeley DB docs:
Usually you find database records by means of the record's key. However, the key that you use for your record will not always contain the information required to provide you with rapid access to the data that you want to retrieve. For example, suppose your database contains records related to users. The key might be a string that is some unique identifier for the person, such as a user ID. Each record's data, however, would likely contain a complex object containing details about people such as names, addresses, phone numbers, and so forth. While your application may frequently want to query a person by user ID (that is, by the information stored in the key), it may also on occasion want to location people by, say, their name. Rather than iterate through all of the records in your database, examining each in turn for a given person's name, you create indexes based on names and then just search that index for the name that you want. You can do this using secondary databases. In DB, the database that contains your data is called a primary database. A database that provides an alternative set of keys to access that data is called a secondary database. In a secondary database, the keys are your alternative (or secondary) index, and the data corresponds to a primary record's key.
From the Berkeley DB docs:
Usually you find database records by means of the record's key. However, the key that you use for your record will not always contain the information required to provide you with rapid access to the data that you want to retrieve. For example, suppose your database contains records related to users. The key might be a string that is some unique identifier for the person, such as a user ID. Each record's data, however, would likely contain a complex object containing details about people such as names, addresses, phone numbers, and so forth. While your application may frequently want to query a person by user ID (that is, by the information stored in the key), it may also on occasion want to location people by, say, their name.
Rather than iterate through all of the records in your database, examining each in turn for a given person's name, you create indexes based on names and then just search that index for the name that you want. You can do this using secondary databases. In DB, the database that contains your data is called a primary database. A database that provides an alternative set of keys to access that data is called a secondary database. In a secondary database, the keys are your alternative (or secondary) index, and the data corresponds to a primary record's key.
This usage scenario can easily be implemented using ZCatalog (as Chris mentioned) - check the ZopeBook for info. Jonathan
On 2006-05-04, Jonathan <dev101@magma.ca> wrote:
From the Berkeley DB docs:
Usually you find database records by means of the record's key. However, the key that you use for your record will not always contain the information required to provide you with rapid access to the data that you want to retrieve. For example, suppose your database contains records related to users. The key might be a string that is some unique identifier for the person, such as a user ID. Each record's data, however, would likely contain a complex object containing details about people such as names, addresses, phone numbers, and so forth. While your application may frequently want to query a person by user ID (that is, by the information stored in the key), it may also on occasion want to location people by, say, their name.
Rather than iterate through all of the records in your database, examining each in turn for a given person's name, you create indexes based on names and then just search that index for the name that you want. You can do this using secondary databases. In DB, the database that contains your data is called a primary database. A database that provides an alternative set of keys to access that data is called a secondary database. In a secondary database, the keys are your alternative (or secondary) index, and the data corresponds to a primary record's key.
This usage scenario can easily be implemented using ZCatalog (as Chris mentioned) - check the ZopeBook for info.
Last year I hacked some ZCatalog replacement because I had a non-zope standalone ZODB application. It is only one single file containing a complete customizable indexer. Perhaps it is also useable here. http://files.banality.de/public/standaloneindexer.py Simon Pamies
Terry Jones wrote:
Usually you find database records by means of the record's key. However, the key that you use for your record will not always contain the information required to provide you with rapid access to the data that you want to retrieve.
Ah, okay, you do this with multiple BTrees in Zope, unless you want to swallow the whole ZCatalog...
For example, suppose your database contains records related to users. The key might be a string that is some unique identifier for the person, such as a user ID.
from BTrees.IOBTree import IOBTree chris = object() id2user = IOBTree() id2user[1234] = chris
is, by the information stored in the key), it may also on occasion want to location people by, say, their name.
from BTrees.OOBTree import OOBTree, OOSet name2user = OOBTree() name2user['chris'] = chris Now, if you have more than one value, you use a set: dan = object() age2user = OOBTree() age2user[27] = OOSet(chris,dan) Although, to be honest, if you're doing all this, you'll likely get more milleage out of the zcatalog than rolling it all yourself... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (4)
-
Chris Withers -
Jonathan -
Simon Pamies -
Terry Jones