You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR is a proof of concept for addressing multiple table namespaces (schemas) in a database. This is to support schemas in Doltgres initially, but could also be used to implement storing multiple databases in the same Dolt commit graph if we wanted to do that. All tables are stored in the root's table map like always, but tables with non-empty schemas have that schema name prepended in its map key, surrounded by null bytes.
There are lots of things that don't work yet. This is what does work:
I am not crazy about the sweeping changes to table-access interfaces in root_val.go. In particular it seems likely to cause errors over time as people forget to include schema names in code changes where necessary, silently breaking doltgres. Another option I considered was to introduce some sort of RootReader interface on top of root value, which you create with a particular schema name, and thereafter all table accesses reference the given schema. There may be places where we have to juggle multiple RootReader instances at once, rather than just asking for qualified table names from a single root. But this is the pattern I used for the boundary between GMS and Dolt and it worked well, so maybe it could work for root_val.go as well.
Regarding a marker approach, we already disallow all tables from the "dolt_" namespace right? Perhaps we could make use of that in some way to form a marker.
This is the route I went with, but instead of dolt_ I used null bytes to offset the schema name.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Companion PRs:
dolthub/vitess#338
dolthub/go-mysql-server#2466
dolthub/doltgresql#181
This PR is a proof of concept for addressing multiple table namespaces (schemas) in a database. This is to support schemas in Doltgres initially, but could also be used to implement storing multiple databases in the same Dolt commit graph if we wanted to do that. All tables are stored in the root's table map like always, but tables with non-empty schemas have that schema name prepended in its map key, surrounded by null bytes.
There are lots of things that don't work yet. This is what does work:
Things I specifically want feedback on:
root_val.go
. In particular it seems likely to cause errors over time as people forget to include schema names in code changes where necessary, silently breaking doltgres. Another option I considered was to introduce some sort ofRootReader
interface on top of root value, which you create with a particular schema name, and thereafter all table accesses reference the given schema. There may be places where we have to juggle multipleRootReader
instances at once, rather than just asking for qualified table names from a single root. But this is the pattern I used for the boundary between GMS and Dolt and it worked well, so maybe it could work forroot_val.go
as well.