On Sep 25, 2007, at 8:52 AM, Stefan H. Holek wrote:
On 24. Sep 2007, at 18:53, Maken Seteva wrote:
I have made a slight modification to my intid util by inheriting
from IntId and overriding _generateId().
I do this to be sure that all new created objects will have an
incrementing number where
the first object created gets id 1, the next gets id 2 and so on.
This way I get for "free" sorting by
Please do not attach additional "meaning" to intids. The value of
an object's intid is (and should be) completely irrelevant.
What do you think about this? Is it "safe" to do this, or have i
forgotten any unforseen oddities
that might occur in the future :O
Your code looks like a conflict-magnet to me. I suggest you read up
on why counting in the ZODB is a bad idea.
It doesn't necessarily do it in chronological order, though.
Looks like a few others besides me actually are giving meaning to
intids as well.. I base my choice of adding meaning to ids from this
post (one approach of reducing sort cost):
Quote (by Jim Fulton http://www.mail-archive.com/[EMAIL PROTECTED]/
Sort your results based on the "primary key" and therefore, pick your
primary key to match your sort results. In terms of the Zope catalog
framework, the primary keys are the document IDs, which are
traditionally chosen randomly. You can pick your primary keys based
on a desired sort order instead. A variation on this theme is to use
multiple sets of document ids, storing multiple sets of ids in each
index. Of course, this approach doesn't help with something like
I *could* use, as the quote states, several ids but why not use the
regular intid (that we already have) for this? As long as I resolve
conflicts of course.
Not fully sure how to resolve conflicts though as I'm quite new to
this. I saw a suggestion on BTrees.Length in another thread. So could
I easily just replace the nextid in my code to use a Length instead?
(and use Length.change to increment the counter).
My best regards
Zope3-users mailing list