Hi Tim,
Tim Peters wrote at 2005-6-29 16:46 -0400:
>I don't hate the feature, but I hate that it's undocumented, and I hate that
>it's untested. I particularly hate that the ClientStorage constructor has
>17 arguments now, and that the docs for its `name` and `storage` arguments
>are incomprehensible when taken together:
>
> storage -- The storage name, defaulting to '1'. The name must
> match one of the storage names supported by the server(s)
> specified by the addr argument. The storage name is
> displayed in the Zope control panel.
This is the server side storage name (as used in the servers configuration,
see below).
> name -- The storage name, defaulting to ''. If this is false,
> str(addr) is used as the storage name.
This is the client side storage name as defined by
"ZODB.BaseStorage.BaseStorage".
It is primarily used for logging and returned by the "getName" method.
Of course, I would expect that the client side name is
automatically composed from the server address and the server
side storage name (I implemented it this way in our modified copy).
As several servers may use the same storage name (for different
storages) and a single server can have multiple storages (of different
name), the client side name should identify both the server and
the (server local) storage name.
In my view, there is no need to provide a different explicit name...
>WTF? I had no idea what either of these were for until I peed away an hour
>trying to guess at a useful answer to Lukas's question. I'm still not sure
>what _possible_ values `storage` can have
Any string acceptable as a "ZConfig" "name".
The "ZEO/schema.xml" tells about this:
<multisection name="+" type="ZODB.storage"
attribute="storages"
required="yes">
<description>
One or more storages that are provided by the ZEO server. The
section names are used as the storage names, and must be unique
within each ZEO storage server. Traditionally, these names
represent small integers starting at '1'.
</description>
</multisection>
Rather than numbers, we are using descriptive names such as
"LexiconArticle", "Laws", "Decisions", ...
> ...
>The end result is that it's more likely for a feature like this to get
>ripped out than rehabilitated (less time, less work, less hassle, leaves
>remaining code clearer and cleaner -- e.g., just getting rid of the
>`storage` docs above would eliminate the confusion of having two arguments
>each claiming to be "the storage name"). That's why I said before that if
>someone wants this, the best way to ensure it sticks around is to contribute
>docs and tests for it.
Above, I already provided a bit of docs (although the English could
probably be improved).
I may also come up with some tests (although my ZODB contributions
do not always find their way into the core ;-) ).
--
Dieter