Alexandre Garel wrote:
> Yes this is intended, the test requirements, are separated from package
> requirements, to avoid extra installs. See ZODB3 setup.py you'll see a
> test_require.
>
> In buildout you can use those requirements telling you need ZODB3 [test] I
> don't know if pip has some way
Nitro wrote:
> packaging: I don't plan to create a package for this as I don't see much
> point in adding yet another package to the clutter of packages surrounding
> zodb.
Just a quick remark: Without being available as a package, your code will
be far less useful (if not outright useless) to a
Nitro wrote:
> Is anybody else interested in having a zodb spatial index?
FWIW: I am.
--
Thomas
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.o
Hi,
I just noticed that while BTrees do implement __getitem__, the method is
missing from BTrees.Interfaces.IBTree. Is this intentional for some reason
or did it just get lost in the hierarchy of interfaces defined in
BTrees.Interfaces?
--
Thomas
__
ZODB.blob.rename_or_copy_blob may silently overwrite existing blob files
since it uses os.rename without checking for the target file first. This
may affect committed data although we remove write permissions after the
commit.
This seems questionable to us, so we wonder whether it is actually desi
Dieter Maurer wrote:
> How often do you need it?
> It is worse the additional index? Especially in view that a storage may
> contain a very large number of transactions?
We've done it differently now anyway, using real iterators which store
their state on the server and get garbage-collected when
Jim Fulton wrote:
>
> On Feb 11, 2008, at 1:25 PM, Christian Theune wrote:
>>
>> There is the pattern like undoInfo/Log and record_iternext which
>> provides context by passing in ranges of records to return + tolerance
>> for ranges that don't exist.
>
>
> I don't think that's going to work h
Jim Fulton wrote:
> IMO, something that packed incrementally, with disk being freed along the
> way, would be a big improvement. This isn't possible with FileStorage.
Just an idea, without having followed FileStorage's history: Has spreading
the file storage across multiple files been considered?
Jim Fulton wrote:
> Chris McDonough did the transaction split off. He's probably the best one
> to answer your other questions.
I know, but then he's subscribed to this list afaik, so I'll just wait for
him to respond.
> If the tests pass without it, then I think it is a safe bet that it can.
>
I found that in the transaction and ZODB packages, some test files are
duplicates of each other:
- The transaction tests contain sampledm.py and test_SampleDataManager.py
which are the same up to defining a test suite for "setup.py test"
support. Is this intentional or some half-finished renam
Jim Fulton wrote:
> I know. At the time I got the interfaces in shape, I was thinking of
> removing this feature. I didn't like it at all and am still a bit
> ambivalent about it. I decided to compromise and leave it in the
> implementation but out of the interfaces.
Removing the feature altogeth
Several storage implementations define a cleanup method, which is another
method that is not currently specified by any interface. (The obvious
candidate would be IStorage.)
We have the impression, however, that this method is never called in
production. The only places it is ever called is in ZOD
The ZEO ClientStorage.getExtensionMethods method is not specified by any
interface currently, but probably it should be, and probably IServeable is
a good place for it. Should we add the method to the interface? The
current way of finding out whether a storage has that method, i.e. trying
to use it
In the current ZODB, the ZEO ClientStorage has a method syn which is not
described by any of the ZODB's interfaces. It does nothing, and other
storages don't have that method at all. OTOH, the only place it is invoked
seems to be in Connection code that is not specific to the ClientStorage
and has
Tim Peters wrote:
> - Edit NEWS.txt by hand, inserting branch-appropriate NEWS for what
> changed in the rest of the merge. Usually this amounts to just
> copying paragraphs from one NEWS.txt to another, changing version
> numbers in an obvious way.
Maybe it's not all that obvious in this
Tim Peters wrote:
> The best idea is to clean it up so that it makes good sense. There's
> lots of historical cruft in the ZODB code base that doesn't make much
> sense anymore.
Hm. To me, this would mean to get rid of the test suites in
src/ZODB/tests and move checks which they do but the test
Tim Peters wrote:
> Looks it got lost in the branches. PersistentMapping.__iter__ was added in
> ZODB 3.4.2, just this August:
>
>http://mail.zope.org/pipermail/zodb-checkins/2005-August/010225.html
>
>Log message for revision 38076:
>Gave PersistentMapping an __iter__ method.
>
Tim Peters wrote:
> ZODB/branches/3.5
My newly added tests for PersistentMapping break here; PersistentMapping
seems to lack __iter__. (PersistentMapping hadn't been tested at all
before.) The suite passes fine on the trunk and the 3.4 and 3.6 branches,
but it fails on 3.5.
Should __iter__ b
Christian Theune wrote:
> The whole testing story together with all the active branches and
> platforms sounds like we want to have some buildbot clients for ZODB as
> well. I could set up a buildbot client on Windows 2k and Linux to test
> various ZODB branches ...
>
> That could be added to the
Julien Anguenot wrote:
> Note I added couple of weeks ago a comment about this within the
> README.txt of ZODB.
Ah, now that you mention it, I found it. I think it's too late in the
file, you trip over the testing before you get to it. That is, I did.
> % export PYTHONPATH=`pwd`/src:$PYTHONP
Tim Peters wrote:
> Things I can't guess include which version of ZODB you're trying this
> with, and exactly what the errors were. Copy+paste generally works a lot
> better than English paraphrasing.
Sorry.
> From the "build/lib.foo" part I guess you're running on Linux.
Right.
> So I tried
Tim Peters wrote:
> I'm the closest thing to a ZODB maintainer there is, and I won't object
> ;-) Go for it!
OK. Right now I have the problem of getting the tests to pass before I
start changing things. Doing just as README.txt says (python2.4 setup.py
build, then python2.4 test.py) earns me wagg
Tim Peters wrote:
> The need for this class has been largely supplanted by the
> ability to subclass directly from dict ...
Yes, that's exactly what I was referring to.
> I agree pop() should be added. Work up a patch, or at least open a bug
> report?
I can do the patch, and I should e
Jeremy Hylton wrote:
> It has been possible to inherit from dictionary since Python 2.2, but
> it is not possible for a persistent object and it would not do what
> you expect even if it were possible. A persistent object has a custom
> C layout and so does dict, so it is not possible to have the
Hi,
I just noticed two things about persistent.PersistentMapping:
- It inherits from UserDict.UserDict. Is there any reason not to inherit
from dict directly, given that this has been possible since Python 2.3
IIRC?
- Not all methods of the mapping interface are handled. In particular,
th
25 matches
Mail list logo
