- 14 Jul, 2020 1 commit
-
-
Kirill Smelkov authored
This is utility to create X function, similar to exc.Raisif, but that would call t.Fatal instead.
-
- 10 Jul, 2020 3 commits
-
-
Kirill Smelkov authored
We will soon need this infrastructure to test other storage drivers.
-
Kirill Smelkov authored
E.g. before: --- FAIL: TestLoad/py (0.22s) zeo_test.go:217: load 0285cbacc06d3a4c:0000000000000007: returned err unexpected: /tmp/zeo484021674/1.fs.zeosock: load 0285cbacc06d3a4c:0000000000000007: 0000000000000007: no such object ; want: /tmp/zeo484021674/1.fs.zeosock: load 0285cbacc06d3a4c:0000000000000007: 0000000000000007: object was deleted @0285cbacc06d3a4c zeo_test.go:217: load 0285cbad858bf2e6:0000000000000006: returned err unexpected: /tmp/zeo484021674/1.fs.zeosock: load 0285cbad858bf2e6:0000000000000006: 0000000000000006: no such object ; want: /tmp/zeo484021674/1.fs.zeosock: load 0285cbad858bf2e6:0000000000000006: 0000000000000006: object was deleted @0285cbad858bf2e6 zeo_test.go:217: load 7fffffffffffffff:0000000000000006: returned err unexpected: /tmp/zeo484021674/1.fs.zeosock: load 7fffffffffffffff:0000000000000006: 0000000000000006: no such object ; want: /tmp/zeo484021674/1.fs.zeosock: load 7fffffffffffffff:0000000000000006: 0000000000000006: object was deleted @0285cbad858bf2e6 zeo_test.go:217: load 7fffffffffffffff:0000000000000007: returned err unexpected: /tmp/zeo484021674/1.fs.zeosock: load 7fffffffffffffff:0000000000000007: 0000000000000007: no such object ; want: /tmp/zeo484021674/1.fs.zeosock: load 7fffffffffffffff:0000000000000007: 0000000000000007: object was deleted @0285cbacc06d3a4c After: --- FAIL: TestLoad/py (0.22s) zeo_test.go:217: load 0285cbacc06d3a4c:0000000000000007: returned err unexpected: have: /tmp/zeo087978981/1.fs.zeosock: load 0285cbacc06d3a4c:0000000000000007: 0000000000000007: no such object want: /tmp/zeo087978981/1.fs.zeosock: load 0285cbacc06d3a4c:0000000000000007: 0000000000000007: object was deleted @0285cbacc06d3a4c zeo_test.go:217: load 0285cbad858bf2e6:0000000000000006: returned err unexpected: have: /tmp/zeo087978981/1.fs.zeosock: load 0285cbad858bf2e6:0000000000000006: 0000000000000006: no such object want: /tmp/zeo087978981/1.fs.zeosock: load 0285cbad858bf2e6:0000000000000006: 0000000000000006: object was deleted @0285cbad858bf2e6 zeo_test.go:217: load 7fffffffffffffff:0000000000000007: returned err unexpected: have: /tmp/zeo087978981/1.fs.zeosock: load 7fffffffffffffff:0000000000000007: 0000000000000007: no such object want: /tmp/zeo087978981/1.fs.zeosock: load 7fffffffffffffff:0000000000000007: 0000000000000007: object was deleted @0285cbacc06d3a4c zeo_test.go:217: load 7fffffffffffffff:0000000000000006: returned err unexpected: have: /tmp/zeo087978981/1.fs.zeosock: load 7fffffffffffffff:0000000000000006: 0000000000000006: no such object want: /tmp/zeo087978981/1.fs.zeosock: load 7fffffffffffffff:0000000000000006: 0000000000000006: object was deleted @0285cbad858bf2e6
-
Kirill Smelkov authored
We will soon need this infrastructure to test other storage drivers.
-
- 07 Jul, 2020 7 commits
-
-
Kirill Smelkov authored
This package already provides parts of infrastructure for ZODB testing (see e.g. 46636b16 and 7f14e2cb), and will be used as the place for such infrastructure. Maybe in the future we'll rename it to something like ztesting, but leaving package name as is for now.
-
Kirill Smelkov authored
See kirr/go123@515a6d14
-
Kirill Smelkov authored
See kirr/go123@515a6d14
-
Kirill Smelkov authored
-
Kirill Smelkov authored
Provide way for users to retrieve Connection -> DB from which it was opened. Wendelin.core 2 might need this to open a second connection given a one.
-
Kirill Smelkov authored
Provide way for users to go from DB -> IStorage for which it was opened. Wendelin.core 2 needs it.
-
Kirill Smelkov authored
Implement "TODO defer stor.Close()" that was sitting there in every subcommand.
-
- 09 Jun, 2020 1 commit
-
-
Kirill Smelkov authored
Julien Muchembled notices that strictly speaking Head could return tid that it receives during its call, not strictly as observed before the call. In other words for which range might be returned it is like below: ...\\\\\\\\\\\↓ ↓////////////... ────────────────────────────────────────── <head call> <sync call> Fixes 151d8b79 (go/zodb: LastTid -> Sync + Head). [1] https://github.com/zopefoundation/ZODB/pull/307#discussion_r436881665
-
- 05 Apr, 2020 2 commits
-
-
Kirill Smelkov authored
This helps when events are printed and logged.
-
Kirill Smelkov authored
-
- 14 Feb, 2020 1 commit
-
-
Kirill Smelkov authored
Paralleling zodbtools@0b6f99da. All test databases in */testdata/ stay as before bit-to-bit the same.
-
- 10 Feb, 2020 4 commits
-
-
Kirill Smelkov authored
The only change is extra LF that is appended to end of 1.zdump.pyok due to nexedi/zodbtools@624aeb09. Correspondingly fix dump on zodbtools/go side.
-
Kirill Smelkov authored
The only update comes from kirr/b@8c9698d6
-
Kirill Smelkov authored
Rerun `go generate` for this package. Updates come due to updated `stringer`. zproto-marshal.go stays the same.
-
Kirill Smelkov authored
When trying to regenerate zproto-marshal.go on a fresh go workspace I got: (neo) (z-dev) (g.env) kirr@deco:~/src/neo/src/lab.nexedi.com/kirr/neo/go/neo/proto$ go generate typecheck: ../../zodb/zodb.go:174:2: could not import lab.nexedi.com/kirr/go123/mem (can't find import: "lab.nexedi.com/kirr/go123/mem") exit status 1 proto.go:57: running "sh": exit status 1 Digging around a bit this turned out to be due to that importer.Default() is using packages in only binary installed form: https://github.com/golang/go/issues/19334#issuecomment-283430322 https://github.com/golang/go/issues/11415 Fix it by using "source" importer which always looks at sources. (zproto-marshal.go stays unchanged after `go generate` rerun)
-
- 16 Jan, 2020 1 commit
-
-
Kirill Smelkov authored
So that Go1.13 and golang.org/x/xerrors understand the wrapping: https://blog.golang.org/go1.13-errors Preserve Cause for compatibility with github.com/pkg/errors.
-
- 12 Apr, 2019 1 commit
-
-
Kirill Smelkov authored
This allows to use proper btree.Node type - not just zodb.IPersistent - in places which expects a tree node.
-
- 12 Mar, 2019 7 commits
-
-
Kirill Smelkov authored
More comments, typos, ...
-
Kirill Smelkov authored
If cache control changes, all objects needs to go through new cache control as what was e.g. pinned before could be in other class from the point of view of new cache control. Tests pending...
-
Kirill Smelkov authored
We already have LiveCacheControl and policy to keep object state in live cache. However that state is currently kept only until the object is present in the cache, and the object is there currently only until there are live pointers to the object from anywhere. If all such pointers go away, LiveCache currently discards the object. Add a way (PCachePinObject) to tell live cache that it must retain an object even if there are no other pointers to it. This is needed for Wendelin.core which semantically relies on some objects to be present in live cache, even if in ghost state, for propagating ZODB invalidations into OS pagecache: https://lab.nexedi.com/kirr/wendelin.core/blob/000bf16359/wcfs/wcfs.go#L245 For symmetry add a way (PCacheDropObject) to tell live cache that it must not retain an object. This makes sense for objects that are read in large only once to avoid needlessly evicting all other objects while making the room for what won't be soon used again. For completeness add also a way (PCacheDropState) to tell live cache that the state of this object should not be cached. This can make sense even for objects that are pinned: for example Wendelin.core pins ZBlk objects to rely on volatile metadata it attaches to them, but have to drop ZBlk state that was loaded from database: that state is propagated to be cached in OS pagecache, and keeping it also in ZODB live cache would just waste RAM. Finally add test to cover LiveCache/LiveCacheControl functionality in detail.
-
Kirill Smelkov authored
We are going to rework LiveCache to support both retaining objects in cache even though if all pointers to them went away (currently such objects disappear from cache), and to tell the cache that such and such object should not be cached at all, e.g. not to evict all other objects on one-time large reads. This will be done by LiveCacheControl giving cache policy classification for an object. Prepare for that and change WantEvict(obj) -> bool to PCacheClassify(obj) PCachePolicy which can give more information to LiveCache about how to handle an object. This is only a preparatory patch as there is neither no new functionality nor fixes here.
-
Kirill Smelkov authored
We already have "testing connection" functionality in common place (was named tPersistentDB -> now tConnection). However the functionality to "setup and use testing database" was inside TestPersistentDB only. Since we are going to add more tests, factor that functionality out of TestPersistentDB into shared infrastructure that could be reused in between tests (-> tDB).
-
Kirill Smelkov authored
It was printing oid instead of obj.
-
Kirill Smelkov authored
Provide functions to: - set cache element - iterate through all elements LiveCache organization will be changed in the following patch, and it is better to keep the knowledge about its internal structure localized.
-
- 10 Mar, 2019 2 commits
-
-
Kirill Smelkov authored
For ZODB we always open database at storage level. Thus `zodb.Open(zurl)` is relevant. At application level we open database creating DB from IStorage and using DB.Open() .
-
Kirill Smelkov authored
Today LastTid is ambiguous: does it return locally cached last transaction ID, or it performs round-trip to server to get more uptodate view of what has been last committed? As the result of this ambiguity some drivers (e.g. FileStorage, ZEO) return cached view, while other drivers (upcoming NEO, living on t branch) was doing the full round-trip. There are also situations where whether or not LastTid performs syncing to server affects semantics: for example if there are two ERP5 nodes and one node commits something into ZODB and conveys the fact that something has been committed via another channel, the second ERP5 node should have a reliable way to observe committed data. But currently there is no such way: on next DB.Open, even with at=0 meaning "use latest transaction" and with opt.NoSync=false, DB.Open uses storage.LastTid() as a way to sync and oops - for some drivers it won't result in real synchronization and thus opened connection could potentially have older view with not yet latest data. To fix this ambiguity require drivers to provide Sync functionality only. That should return ID of last transaction committed to storage data as observed from some time _afterwards_ Sync call was made. In other words for particular client-server case, Sync cannot return cached view of storage and has to perform round-trip to the server. At IStorage level we provide two entry points: Sync, to perform syncing, and Head that returns database head (last transaction ID) as viewed by local cache without any synchronization. Please see changes to IStorageDriver and IStorage interfaces for details. The rest of the changes are: - teach zodb.storage (the IStorage implementer) to actually implement Sync/Head. - adapt zodb.DB to perform Sync for !opt.NoSync case. - teach FileStorage to do proper syncing instead of returning local cache. - teach ZEO to perform "lastTransaction" RPC call for syncing instead of returning local cache. - adapt the rest of the tree to interfaces change.
-
- 08 Mar, 2019 2 commits
-
-
Kirill Smelkov authored
If we use only the rule that we keep last 10 minutes of database history, and commits come less often than that - e.g. once per 30 minutes, on every new commit we'll be throwing away all δtail data, which would result on completely throwing away live cache on every DB.Open . Add another rule to cover seldom updates spectrum so that we never throw till empty δtail and keep at least 10 elements in δtail queue. This will make sure that live cache is preserved even when updates to database are seldom to come. Tests pending...
-
Kirill Smelkov authored
This gives access to raw data stored in ΔTail. We'll need this in the next commit, as well as going through raw δtail data is also generally useful.
-
- 06 Mar, 2019 6 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
Add low-level option to resync Connection to another database state with preserving its live cache. Wendelin.core needs this for its main ZODB connection because it needs to carefully propagate ZODB invalidations into file invalidations and semantically relies on objects staying in ZODB live cache for this to work correctly: https://lab.nexedi.com/kirr/wendelin.core/blob/455a54425c/wcfs/wcfs.go#L245
-
Kirill Smelkov authored
Implement invalidation handling to teach DB to reuse Connections from connection pool: after connection is returned to the pool on transaction completion, we can use this connection for next DB.Open(at) request, by seeing which objects we changed in conn.at..at range and invalidating those objects in connection live cache. To know which objects were changed, DB adds watch on its storage and maintains some history tail (using ΔTail - see previous commit). Finally add test for both DB and Connection, and also for Persistent, LiveCache, ... - as all those application-level components are tightly inter-related.
-
Kirill Smelkov authored
Add ΔTail - utility class to keep track of history tail of revisional changes. This will be needed for both DB (to handle invalidations) and for raw Cache(*). It also might be useful in places outside of zodb/go - for example WCFS from Wendelin.core uses ΔTail to keep track of which ZODB revision changed which block of file(+). Please see ΔTail comments for details. (*) to check a bit ahead on load to see whether loaded serial is actually the latest one for ≤ Cache.head, and, if yes, mark corresponding cache entry as having .head="current" so that the entry coverage could be extended when Cache.head is extended to cover more database state instead of loading the same data from the database again. (+) that's why we have δtail.go.cat-generic, so that third-party packages could adapt ΔTail to needed types.
-
Kirill Smelkov authored
We are going to add more options. Adopt "!" prefix as "no" for something. Make the code flow in ConnOptions more suitable for further additions without changing formatter for previous option.
-
Kirill Smelkov authored
DB is a "handle to database". It has to be closed to release its resources when no longer needed. We don't have to release anything currently, but that will soon change in a followup patch.
-
- 20 Feb, 2019 2 commits
-
-
Kirill Smelkov authored
Due to forgotten ... it was not passing prepared argv as argv to fmt.Errorf, but as a single slice argument. The result was messy, for example persistent_test.go:176: deactivate refcnt < 0: panic error unexpected: have: "[t.zodb.MyObject 000000000000000c](%!s(MISSING)): deactivate: refcnt < 0" want: "t.zodb.MyObject(000000000000000c): deactivate: refcnt < 0" Using the occasion add details to deactivate refcnt panic, which made me to discover this bug.
-
Kirill Smelkov authored
Seeing all problems helps to understand what is going on, compared to e.g. if it complains only about .jar being wrong.
-