Backward compatibility (was Re: Announcing Newt DB, the amphibious database)

On Thu, Feb 23, 2017 at 12:05 PM, David Glick (Glick Software) <
[email protected]> wrote:

> On 2/23/17 5:55 AM, Jim Fulton wrote:
>
>
>
> On Thu, Feb 23, 2017 at 8:46 AM, Jason Madden <
> [email protected]> wrote:
>
>>
>> > On Feb 23, 2017, at 07:37, Mike Metcalfe <[email protected]> wrote:
>> >
>> > I'm trying to create a local instance with RelStorage but getting
>> version/pinning issues when running buildout in a plone 4.3.10 instance. So
>> far I've pinned:
>> > transaction = 2.1.0
>> > relstorage = 2.1a1
>> >
>> > With these pins the buildout completes successfully but now I cannot
>> start the client, I get:
>> >   File "/home/mike/instances/sqltlm/buildout-cache/eggs/RelStorage-
>> 2.1a1-py2.7-linux-x86_64.egg/relstorage/_compat.py", line 82, in <module>
>> >     from ZODB._compat import BytesIO
>> > ImportError: No module named _compat
>> >
>> > I'll keep going but do you (or anyone else) have a KGV dev buildout for
>> plone 4.3.x?
>>
>> Plone 4.x requires ZODB3 and hence RelStorage 1.6. Initially this was due
>> to changes in BTrees 4, but that reason is no longer applicable. It *may*
>> be possible to get Plone 4.x to work with ZODB 5 and RelStorage 2, but
>> you'd be in uncharted waters. The official work to make that happen is
>> going on in Plone 6: https://www.starzel.de/blog/towards-plone-6
>
>
> Oh man, I keep forgetting about this, because... ZODB3. Really?  I gather
> ZODB3 is what debian distributes as well.
>
> Of course, I get that this may be due to the BTree issue.  I'm
> disappointed that this wasn't escalated years ago.  (It may have been and I
> didn't appreciate it, but this is a major issue, people should have pushed
> this.)
>
> So when I say newt works with Plone, I'm wrong because of this issue.
> whimper.
>
> It would be really great of current stable plone used current stable ZODB
> and RelStorage. I wonder what that would take.
>
>
> Yeah, I think we got hung up on the None-in-BTree issue, and
> misunderstanding that that was a limitation forced by supporting Python 3
> rather than just a policy choice which we could push for changing.
>
> Plone 6 will support latest stable ZODB; it already does on the Zope 4
> compatibility branch which has all tests passing.
>
> Supporting ZODB 5 in Plone 5 would require a new Zope 2.13.x release that
> handles transaction notes as unicode when transaction 2.x is present but as
> bytes when transaction 1.x is present (for backwards-compatibility within
> the minor release). Or a way to tell transaction which sort of string to
> use in its note interface.
>

If the transaction package was changed to accept and issue a deprecation
warning when it got bytes, would that allow current stable Plone to use
current stable ZODB and RelStorage?

On a personal level, it's disheartening to *realize* (I should have know,
but) that after all the work I've put into ZODB over the past several
months (well, several years actually, but especially the past few months),
none of it benefits most current ZODB users. I don't say this to complain,
but to let y'all know that you aren't doing us any favors by letting us
break things.

Jim

-- 
Jim Fulton
http://jimfulton.info

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.