Skip to content

Commit

Permalink
Fixed maxtid, copying value from ZEO.
Browse files Browse the repository at this point in the history 
Changed it to the value corresponding to the maximim *signed*
big-endian 64-bit integer, because of LxBTrees.

Note that this value isn't used anywhere in ZODB yet.

Maybe it should be.
  • Loading branch information
Jim Fulton committed Jun 7, 2016
1 parent 5bb8a81 commit baee84a
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion src/ZODB/utils.py
View file
Original file line number Diff line number Diff line change
Expand Up @@ -103,7 +103,7 @@ def byte_chr(int):

z64 = b'\0' * 8

maxtid = b'\xff' * 8
maxtid = b'\x7f\xff\xff\xff\xff\xff\xff\xff'

assert sys.hexversion >= 0x02030000

Expand Down

4 comments on commit baee84a

@vpelletier
Copy link
Contributor

@vpelletier vpelletier commented on baee84a Jun 8, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am puzzled by the commit message:
Do LxBtrees care about TIDs ?
I can imagine them caring about OIDs (as they have to manipulate them for persistence), but I can't imagine a reason for them to care about transaction identifiers.
Also, is it really specific to L variant ? I thought L meant that keys could be just any long int (maybe signed, maybe not) fully controlled by btree user.

@tseaver
Copy link
Member

@tseaver tseaver commented on baee84a Jun 8, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LxBTrees use Py_LongLong (a signed type) for keys. One major use is for forward indexes, mapping integral document IDs to the values for the given document in that index. I can't think of any place off hand which uses TIDs as keys, but that doesn't mean @jimfulton doesn't have a usecase in mind.

@jimfulton
Copy link
Member

@jimfulton jimfulton commented on baee84a Jun 8, 2016 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vpelletier
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand, I was only thinking about LxBTrees as they get stored inside a ZODB (ex: BTreeFolder2), and not as used in fsindex.
As for TID & OID being 64bits, I think there is too much code outside of ZODB which peeks at these values (actually mostly tids: Zope historian class, ...) to be able to change them. And I guess that 64 or 63 bits should be large enough anyway.

This corresponds to a TimeStamp of 5908-11-23 02:08.

Yes, out of curiosity I did the check too. Moving from year 9000 to 5900 :).

Please sign in to comment.