Hi All, I'm going to be running some basic performance testing against this new TinkerGraph transaction implementation, the current TinkerGraph and the Neo4jGraph. The goal would be to ensure that the differences aren't too large so that users would be more willing to use the new TinkerGraph with transaction support. Below is my current proposed list of tests to run. Note that the data used is Kelvin's air-routes-latest.
Read tests: 1. Test a query that traverses through the entire graph multiple times. Create tests: 1. Test creating a graph with power law distribution. Update tests: 1. Test randomly moving edges. 2. Test randomly updates properties on different elements. 3. Test updating properties on central elements. 4. Test reading and updating a property on a random element. 5. Test reading and updating a property on a central element. 6. Test upserting elements (MergeE/MergeV). Delete tests: 1. Test deleting random edges. 2. Test deleting random vertices. 3. Test deleting central vertices. There will also be testing for rollback. Please let me know if you think there are any important tests that have been missed. Thanks, Ken On Thu, Jun 15, 2023 at 10:18 PM Valentyn Kahamlyk <valent...@bitquilltech.com.invalid> wrote: > 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 > >> > > >
