Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Implement config definition caching within a transaction #21

Closed
2 tasks done
tobiemh opened this issue Aug 8, 2022 · 0 comments
Closed
2 tasks done
Assignees
Labels
feature New feature or request

Comments

@tobiemh
Copy link
Member

tobiemh commented Aug 8, 2022

Is your feature request related to a problem?

Currently within a transaction, TABLE definitions, EVENT definitions, FIELD definitions, INDEX definitions, and foreign TABLE AS definitions are fetched for every record when reading or writing records.

Ideally we should only fetch the definitions once, and then use the cached values when fetching them for subsequent record processing.

Describe the solution

Use an in-transaction cache to store and cache configuration table records once they have been retrieved for the first time within a transaction.

This can be used when retrieving:

DEFINE TABLE statements for the document table
DEFINE EVENT statements for the document events
DEFINE FIELD statements for the document fields
DEFINE INDEX statements for the document indexes
DEFINE TABLE AS statements for the document foreign tables

Alternative methods

No alternative methods.

SurrealDB version

surreal 1.0.0-beta.5 for macos on aarch64

Contact Details

No response

Is there an existing issue for this?

  • I have searched the existing issues

Code of Conduct

  • I agree to follow this project's Code of Conduct
@tobiemh tobiemh added the feature New feature or request label Aug 8, 2022
@tobiemh tobiemh self-assigned this Aug 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant