I am programming in python 2.3. and use the berkeley-database 4.2. and
have a problem with the storing of datas.
--
#! /usr/bin/python
from bsddb3 import db
Datei = db.DB()
Datei.open('Test bdb')
print Datei.keys()
Datei.put('FF', '1FF')
Datei['KK'] = '1KK'
Datei.close(db.DB_NOSYNC)
--
I want to and have to store the key-value-pairs separatey via put. This
works.
But I dont want to store any pair that I created or only looked at
without using put; therefore I close the db with the flag DB_NOSYNC.
But this dont works, because in the second run the "KK"-key is printed.
Where`s my mistake?

Tanks
Dada

* Dada:

I think you assumption that

db[key] = value

and

b.put('key', 'value')

behave differently in this regard is flawed. There's a difference,
but only for databases with duplicates, which is of no concern here.

* Dada:

I think you assumption that

db[key] = value

and

b.put(key, value)

behave differently in this regard is flawed. There's a difference,
but only for databases with duplicates, which is of no concern here.

Well,
if there is in my application no difference between " Datei.put('FF',
'1FF')" and "Datei['FF'] = '1FF'", then it`s very bad (may be).
My fundamental problem is this:
Two (or more) users are working with the database. Both may work
with/read the same key-value-pair of the db at the same time. The first
user is only looking at the data, and the second is correcting the data
(or vice versa). But the second is the first, who stores to the db. If
then the first user also exits the subprogram, .flush() or .close()
would store the old value on the new, corrected value. That`s terrible.
That the first only sees the old value, doesn`t matter.
In the subprogramm I can find out, whether the user chanced the value
or not. But I need a method, to store only explicitly named (the
chanced or new) data and not all the memory.
I`m now rewriting my program from lists, stored in simple files, to
that key-value-pairs, stored in the db. Therefore I yet don`t know, is
there any need for me to use "Datei['FF'] = '1FF'" beside the method
..put. If not, then there would be no problem - am I right?

Thanks
Dada

* Dada:

You need some kind of locking to prevent this, either at the Berkeley
DB level, or within your application. Is there any particular reason
why you do not use transactions?

I first got in touch with databases only a few days ago. I now looked
up in the manual concerning "transaction"; I found the Cursor-Method.
It seems to me a little bit more complex.
I thought to do it this way:
(The database contains 100-200 (not more) records (key/data pair), one
data consists of 32 subdata.)
At the beginning of the program all records are loaded. Then is made a
working-copy in order not to touch a put- or update-action. I decided
to load all records, because if the user is searching for a definite
record, may be, he don`t knows the key but part of the data. And it`s
faster to do this in the memory.
The users then may create new records or correct existing in their own
working memory. Request for correction of an definte (old) record
always goes to any - but only one - user. Therefore there is no need to
look at the new records of another user. This would be only on the next
day, and then the program is started again.
The program logs, which records are new or corrected. And only these
record are stored at the end.
I think, this works. May be, it`s not so elegant. Later may be, with
more database competence, i would do it another way. I hope, that there
is now logical mistake and
thanks for help
Dada

* Dada:

Problems can occur if the same records are edited by different users.
This may lead to data loss.

There is no generally applicable solution for this kind of problem.
Any introductory text on transaction processing will give you some
ideas of what can be done. For example, it is possible to implement
the read -- uper update -- write cycle as follows:

1. Start a first transaction.

2. Read the conceptual record from the database (this can involve
access to multiple database files).

3. End the first transaction.

4. Make an in-memory copy of the record for later reference.

5. Present the record to the user for editing, and wait until the
users saves his or her edits. This operation can block
indefinitely (because you don't know when the user will react).

6. Start a second transaction.

7. Read the record from the database, and compare it to the copy
made in step 4. If there is a difference, tell the user about
the conflict, update the in-memory copy of the record, and go to
step 5.

8. Write the edited record to the database.

9. Commit the second transaction.

It is also possible to include a version number in the record to
detect concurrent changes. Radically different approaches also exist.
For example, you could represent the user edits as some kind of delta,
in a way that all such deltas commute.