[Zope] Non-bloating counter/access logger solution

[Wankyu Choi]

>Use a BTrees.Length.Length object.  See Products.ZCatalog.Catalog for =
an
example of its usage.

Guess that would work for the counter problem since the counter property
holds an integer value.

But what if I wanted to implement a complete access logger which =
requires
string properties for IP addresses or usernames, etc?

I took a look at the source code of the Length object and the =
_p_independent
method looks interesting.

If I take the Length source code and make it work for other types than
integer, say strings, lists, dictionaries, would that work too?

Thanks in advance.

Wankyu Choi
---------------------------------------------------------------
  Wankyu Choi
  CEO/President
  NeoQuest Communications, Inc.
  http://www.zoper.net
  http://www.neoboard.net
---------------------------------------------------------------  =20



On Thu, 2003-06-12 at 10:46, Wankyu Choi wrote:
> Hi all,
>=20
> I know the topic has been discussed a lot but I found little help so=20
> far.
>=20
> I want to implement a simple counter or a complete access logger for=20
> ZOPE objects.
>=20
> Here are my (and many others') problems regarding this:
>=20
> - ZODB bloats. Whenever the value of a counter property gets updated,=20
> the host object is copied doubling its size.
>=20
> - Too many read/write conflicts. No matter how little traffic you=20
> expect, you get tons of read/write conflict errors.
>=20
> I thought about saving counter values/logs in an external storage like =

> a MySQL table or an external file in order to dupe ZODB into thinking=20
> no change has been made to the object in question. But that doesn't=20
> seem so elegant and generic.
>=20
> Please share your ideas resolving this issue.
>=20
> I have yet to study the internals of ZODB, but can't it have a way to=20
> update only the designated properties of a persistent object? If not=20
> possible, why? ( to avoid bloating ZODB  )
>=20
> Committing a whole object when its access log gets updated lead to=20
> excessive conflict errors. By updating only the counter property, for=20
> example, the odds of having conflicts would decrease to a substantial=20
> degree.
>=20
> Best regards,
> Wankyu Choi
> ---------------------------------------------------------------
>   Wankyu Choi
>   CEO/President
>   NeoQuest Communications, Inc.
>   http://www.zoper.net
>   http://www.neoboard.net
> ---------------------------------------------------------------  =20
>=20
>=20
>=20
>=20
> _______________________________________________
> Zope maillist  -  Zope@zope.org=20
> http://mail.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope-dev )