Hi all, I'm working on transactions implementation and I would like to discuss testing of this feature.
Currently available options for tests in TinkerPop: 1. Unit tests. For development I wrote bunch of unit tests for the newly introduced TinkerTransactionGraph because they are easier to make and much more convenient to debug. However, these tests are very complicated to be reused by other providers. 2. Gherkin tests. This is the best option for providers to test some features. However, the current implementation does not support many of the abilities needed to test transactions, for example multi-step tests and multi-threaded tests. The ideal solution would be to add such features, but unfortunately it takes a lot of time and effort. For basic checks of TinkerTransactionGraph existing Gherkin tests are already used. 3. Integration tests. We have 2 kinds of integration tests in `gremlin-test` a) process tests are mirror of Gherkin tests with some small differences. b) structure tests are probably the best candidate to use for TinkerTransactionGraph. There is already a set of tests for transactions in TransactionTest and I can add more cases there. These tests will be used in a similar way to TinkerGraphStructureStandardTest. 4. Gremlin Server tests. I think these tests have a different responsibility. 5. GLV tests. All GLV's already have transaction tests and we can extend them to use TinkerTransactionGraph at server-side. To summarize I suggest using structure tests to verify transaction implementation. Regards, Valentyn On Wed, May 10, 2023 at 2:59 PM Valentyn Kahamlyk < valent...@bitquilltech.com> wrote: > Hi all, > > I opened PR with a detailed proposal for transaction implementation: > https://github.com/apache/tinkerpop/pull/2054. > > Regards, Valentyn > > On Mon, Feb 27, 2023 at 1:22 PM Valentyn Kahamlyk < > valent...@bitquilltech.com> wrote: > >> Hi all, >> >> Now, if you need to use transactions in tinkerpop, the only solution is >> to use the Neo4J plugin. Unfortunately, this plugin has not been updated >> for a long time and is only compatible with Neo4J version 3.4, which >> reached end of life in March, 2020. >> >> I propose to implement native transaction support in TinkerGraph. >> >> The most interesting question to discuss is the level of isolation in SQL >> 92 terms. There are 5 options to choose from: `Read uncommitted`, `Read >> committed`, `Repeatable read`, `Snapshot` and `Serializable`. >> >> In terms of balancing complexity of implementation and functionality, I >> think the most optimal option is `Read committed` or `Repeatable read`. >> >> I hope to implement `Read committed`, it is enough to add versions to the >> Vertices and Edges, add list of updated Elements in Graph. >> Write lock can be Vertex-level and Edge-level. >> >> Regards, Valentyn >> >
