In the projects I was involved, ZODB3 3.11.a3 (not ZODB 4) has hurt more
than it has helped.
In particular, the banishing of standard comparison from BTrees has made
existing data break on an instance where ZODB3 was accidentally upgraded
from 3.10.5 to 3.11a3 by pip 1.4 (i.e. a BTree containing a None as key,
that happily worked on 3.10, failed to load, during setstate() under
3.11a3, making the data impossible to fix until I reverted ZODB3 back to
3.10, a non-trivial operation requiring manual uninstall of multiple
packages: ZODB, BTrees, persistent).
Not that I disagree with the comparison change, mind you, but if ZODB3
3.11a3 never existed, and people had to explicitly install ZODB to get the
new version, that would have been better overall.
Since erasing ZODB 3.11.a3 isn't really an option, I agree with the last
option of not releasing a final version of ZODB3 3.11.
Cheers,
Leo
On Sun, Sep 29, 2013 at 1:06 PM, Jim Fulton wrote:
> TimeStamps are used mainly to convert between high-level
> date-time representations and 8-byte binary transaction IDs.
> Historically, a TimeStamp's repr was used to retrieve the binary
> representation. repr was used because, under the hood, slots
> are much faster to access than methods.
>
> In ZODB 3.3, a TimeStamp raw method was added to retrieve
> the binary data for a time stamp. I wasn't actually aware of this
> until recently. From an API point of view, using raw rather than
> repr is cleaner. I don't know if the performance implications
> are significant, though probably not.
>
> In Python 3, __repr__ returns Unicode, rather than binary data,
> so it's no-longer possible to use it to get the binary representation
> of a time stamp. TimeStamp's __repr__ was changed to
> return the repr of it's binary data. Python 3 was going to have
> to be broken, but this was also a breaking change for Python 2.
>
> I don't remember this issue being raised earlier. If so, I missed it.
>
> In any case, going forward, it's best to embrace raw() as the correct
> way to get the binary representation of time stamps. This is
> mainly a heads up for people porting to ZODB 4.
>
> I don't really see much value in returning the repr of the binary
> data. I'd at least wrap the string in a TimeStamp call, something
> like "TimeStamp(b'...').
>
> I'd hoped that ZODB 4.0 would be backward compatible with
> ZODB3. That's why ZODB3 3.11 is a meta package that
> requires the ZODB 4 packages. Unfortunately, this means
> that ZODB3 3.11 isn't backward compatible. Fortunately,
> ZODB 3.11.0 is still in alpha. :)
>
> I think the best option is to release what is currently
> ZODB3 3.11.0a3 as ZODB3 4.0.0. This will allow
> packages that depend on ZODB3 to be used with
> ZODB 4, but it will clearly label the ZODB4 4.0.0 release
> as not backward compatible.
>
> Another option is to leave things as they are.
> Since buildout 2, and now pip, prefer final releases,
> existing applications that use current buildout or pip
> aren't broken by ZODB3 3.11a3, even if they don't
> pin versions. If someone wants to mix ZODB3 and
> ZODB 4, they can explicitly require ZODB3 3.11a3.
>
> Thoughts?
>
> Jim
>
> --
> Jim Fulton
> http://www.linkedin.com/in/jimfulton
> ___
> For more information about ZODB, see http://zodb.org/
>
> ZODB-Dev mailing list - ZODB-Dev@zope.org
> https://mail.zope.org/mailman/listinfo/zodb-dev
>
___
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
