Skip to content
This repository was archived by the owner on Oct 9, 2023. It is now read-only.

Implement native calls from Python Driver to Rust Driver #304

Merged
merged 66 commits into from
Aug 23, 2023

Conversation

dmikhalin
Copy link
Contributor

What is the goal of this PR?

We replace the direct implementation of the client side of the TypeDB protocol in Python with native calls to the Rust client over FFI.

What are the changes implemented in this PR?

  • merge TypeDBClient and ClusterClient into single Client, following the protocol merge;
  • remove Remote variants of Concepts; Concept API calls now require a Transaction to be provided;
  • make Value "generic" over its value type, which allows us to collapse all the Attribute.<Type>s into a single Attribute class;
  • associate each top-level class (Client, Session, Concept, etc.) with its native representation on the Rust side;
  • replace Python method implementations with calls using the native representation over FFI.

@typedb-bot
Copy link
Member

typedb-bot commented Aug 2, 2023

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.


Trivial Change

  • This change is trivial and does not require a code or architecture review.

Code

  • Packages, classes, and methods have a single domain of responsibility.
  • Packages, classes, and methods are grouped into cohesive and consistent domain model.
  • The code is canonical and the minimum required to achieve the goal.
  • Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
  • Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
  • The code is algorithmically efficient and scalable for the whole application.

Architecture

  • Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
  • Any required build and release automations are updated and/or implemented.
  • Any new components follows a consistent style with respect to the pre-existing codebase.
  • The architecture intuitively reflects the application domain, and is easy to understand.
  • The architecture has a well-defined hierarchy of encapsulated components.
  • The architecture is extensible and scalable.

Copy link
Member

@dmitrii-ubskii dmitrii-ubskii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! These changes definitely make the client a lot tidier.

Left a few style comments.

@@ -18,10 +18,14 @@
# specific language governing permissions and limitations
# under the License.
#

from __future__ import annotations
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this used?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we import not all classes used in type annotations.

Comment on lines 30 to 28
from typedb.api.concept.thing.attribute import Attribute, RemoteAttribute
from typedb.api.concept.thing.entity import Entity, RemoteEntity
from typedb.api.concept.thing.relation import Relation, RemoteRelation
from typedb.api.concept.thing.thing import Thing, RemoteThing
from typedb.api.concept.type.attribute_type import AttributeType, RemoteAttributeType
from typedb.api.concept.type.entity_type import EntityType, RemoteEntityType
from typedb.api.concept.type.relation_type import RelationType, RemoteRelationType
from typedb.api.concept.type.role_type import RoleType, RemoteRoleType
from typedb.api.concept.type.thing_type import ThingType, RemoteThingType
from typedb.api.concept.type.type import Type, RemoteType
from typedb.api.connection.transaction import TypeDBTransaction
from typedb.api.concept import thing, type, value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably keep individual imports. That's what we're using everywhere else.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need it to avoid circular imports.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Method .of became concept_of function in the separate concept_factory.py file.

Comment on lines 47 to 48
context.option_setters = {option: lambda options, value: setattr(options, option.replace("-", "_"), value) for option in
["session-idle-timeout-millis", "transaction-timeout-millis"]}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We lost int(value) in this change

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

value type check has been moved to the step parser.

context.get(var2))
assert False;
except TypeDBClientException:
except (TypeDBClientException, RuntimeError):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be more specific than RuntimeError?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no more specific exceptions in SWIG's list of possible python exceptions.

from typedb.concept.thing.thing import _Thing, _RemoteThing
from typedb.common.streamer import Streamer
from typedb.concept.concept_factory import relation_type_of, role_type_of, thing_of
from typedb.concept.thing.thing import _Thing
from typedb.concept.type.role_type import _RoleType
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need this import here, because we use role_type_of(). But without direct importing of role_type.py Bazel think that we don't need it and removes this file. One should investigate this behaviour.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We added this file to have all inconvenient module imports in one place.

def vaticle_dependencies():
git_repository(
name = "vaticle_dependencies",
remote = "https://github.com/vaticle/dependencies",
commit = "51fdda8c935d5f9fc34bfdf41b0a6ac1ca77e2ee", # sync-marker: do not remove this comment, this is used for sync-dependencies by @vaticle_dependencies
remote = "https://github.com/dmikhalin/dependencies",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't forget to PR this before we merge this PR

--server.address=127.0.0.1:$PORT \
--server.internal-address.zeromq=127.0.0.1:$(($PORT+1)) \
--server.internal-address.grpc=127.0.0.1:$(($PORT+2)) \
--server.address=localhost:$PORT \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added an asana task for Dmitrii U to try to upgrade tonic so we can use either localhost or 127.0.0.1, since having that option is pretty nice

remote = "https://github.com/dmikhalin/typedb-client-java",
commit = "8b3dac1e497a66a372450ac64e0be1a145ef8f27" # sync-marker: do not remove this comment, this is used for sync-dependencies by @vaticle_factory_tracing
)
# native.local_repository(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete before merging

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants