On Oct 13, 2005, at 11:11 AM, Oleg Broytmann wrote:

> Hello!
>
> On Sun, Oct 09, 2005 at 05:49:33PM -0400, David Binger wrote:
>
>> On Oct 9, 2005, at 4:51 PM, Oleg Broytmann wrote:
>>
>>>   Can I have a serial (autoincremented) counter? Should I? They
>>> are useful
>>> in cases when I don't have an interesting distinguishing features
>>> in my
>>> objects. For example, if I want to store a list of FTP servers I can
>>> distinguish them by their URLs; hence I can use URLs as indices.
>>> But if I
>>> want to store access_log elements - there are no such distinguishing
>>> elements. Even the full tuple (time, client IP, URL) can occur many
>>> times
>>> (many concurrent queries from a program like ApacheBenchmark; or a
>>> huge
>>> network behind a NAT with a single external IP). Autoincremented
>>> counter
>>> seems to be the best way to generate names (indices).
>>>
>>
>> I think I would do that as a BTree whose values are Persistent
>> instances with a single "int" attribute.
>>
>
>    Keys, not values? Or I've missed something important here...

I think I did not understand the purpose of these counters.
I was thinking the keys would be URLs and the values would be
the "counters", but now I think I see what you meant.

BTrees have a fast get_max_item() method.  You could
retrieve the maximal item, and insert a new item whose
key is the key of the old item, plus 1.

If you are planning to log directly to the database, though, you
need to be very careful about the design.  If lots of writers
are writing frequently to the same instance (as in the same BNode
of the BTree), they will be hindered by lots of write conflicts.